Live data from Hacker News

SQLite: Past, Present, and Future

vldb.org

51–60 of 147 posts

Re: SQLite: Past, Present, and Future

#51

>SQLite is primarily designed for fast online transaction processing (OLTP), employing row-oriented execution and a B-tree storage format. I found that claim to be fairly surprising, SQLite is pretty bad when it comes to transactions per second. SQLite even owns up to it in the FAQ: >it will only do a few dozen transactions per second.

> SQLite is pretty bad when it comes to transactions per second. SQLite even owns up to it in the FAQ: "it will only do a few dozen transactions per second." That is an extremely poor quote taken way out of context. The full quote is: FAQ: "[Question] INSERT is really slow - I can only do few dozen INSERTs per second. [Answer] Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average d…

Given the prevalence of SSDs these days the figure might be out of date as well.

Re: SQLite: Past, Present, and Future

#52
post #42

I shared some notes on this on my blog, because I'm guessing a lot of people aren't quite invested enough to read through the whole paper: https://simonwillison.net/2022/Sep/1/sqlite-duckdb-paper/

Thank you for this. Big fan of your blog and all your contributions to Django

Re: SQLite: Past, Present, and Future

#53

my ipad won’t let me search through the PDF, but i couldn’t find where “SSB” was defined, if anywhere. i did not see it defined in the first paragraph, which is where it is first used. everyone: not all of your readers are domain experts. omissions like this are infuriating.

came here to ask this. I wondered if it was a typo for SSD!

Re: SQLite: Past, Present, and Future

#54

>SQLite is primarily designed for fast online transaction processing (OLTP), employing row-oriented execution and a B-tree storage format. I found that claim to be fairly surprising, SQLite is pretty bad when it comes to transactions per second. SQLite even owns up to it in the FAQ: >it will only do a few dozen transactions per second.

> SQLite is pretty bad when it comes to transactions per second. SQLite even owns up to it in the FAQ: "it will only do a few dozen transactions per second." That is an extremely poor quote taken way out of context. The full quote is: FAQ: "[Question] INSERT is really slow - I can only do few dozen INSERTs per second. [Answer] Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average d…

Yeah my GP got me confused. I remember doing 40k inserts/s in a trading strategy backtesting program with Go and SQLite. Reads were on the same magnitude, I want to say around 90k/s. My bottleneck was CPU.

Re: SQLite: Past, Present, and Future

#55

Earlier quoted context omitted.

Here's sqlite doing 100 million inserts in 33 seconds which should fit into nearly every workload, though it is batched. https://avi.im/blag/2021/fast-sqlite-inserts/ So write contention from multiple connections is what you're talking about, versus a single process using sqlite?

No durability guarantee is a showstopper for any serious use case

If it's good enough for avionics and nuclear subs, it's probably good enough for most web apps.

Re: SQLite: Past, Present, and Future

#56
post #27

Earlier quoted context omitted.

Is it the SQL dialect there lacking or is it the built-in functions? I agree that SQLite default functionality is very thin compared to PostgreSQL - especially with respect to things like date manipulation - but you can extend it with more SQL functions (and table-valued functions) very easily.

I like SQLite (qualifying not for you, simonw, but for others). But I hate that I can't be lazy by using arrays in SQLite... because they don't exist. group_concat is a poor approximation. Also, I genuinely dislike how loose SQLite is with allowed syntax. Probably it's preference. But even interactively I prefer to know immediately that I messed up a query. SQLite is so forgiving I've often wasted time trying to unde…

I'm increasingly finding myself using SQLite's JSON features for array stuff - they're surprisingly convenient once you get into the habit of using them. A couple of recent examples:

- https://til.simonwillison.net/sqlite/sort-by-number-of-json-...

- https://til.simonwillison.net/sqlite/function-list#user-cont...

Re: SQLite: Past, Present, and Future

#57
post #27

Earlier quoted context omitted.

Is it the SQL dialect there lacking or is it the built-in functions? I agree that SQLite default functionality is very thin compared to PostgreSQL - especially with respect to things like date manipulation - but you can extend it with more SQL functions (and table-valued functions) very easily.

Depends on what easily means. Sqlite can't do custom format date parsing and regex extract. How do we extend something like this? If we go beyond a simple function to window function, I imagine it would be even harder. At this point, we nlmight as well use postgres.

Funny you should mention those specific examples - I have Datasette plugins adding custom SQL functions to SQLite for both of them!

- https://datasette.io/plugins/datasette-dateutil

- https://datasette.io/plugins/datasette-rure

Re: SQLite: Past, Present, and Future

#58
"While it continues to be the most widely used database engine in the world"

It realy depends what do you mean by that, yes it's shipping in every phones and browser, but I don't consider that as a database. Is the windows registry a database?

Oracle, MySQL, PG, MSSQL are the most widly used DB in the world, the web runs on those not SQLite.

Re: SQLite: Past, Present, and Future

#59

my ipad won’t let me search through the PDF, but i couldn’t find where “SSB” was defined, if anywhere. i did not see it defined in the first paragraph, which is where it is first used. everyone: not all of your readers are domain experts. omissions like this are infuriating.

Just fyi: if you’re viewing the PDF in Safari on your iPad, you can search by typing into Safari’s Location Bar and then choosing “Find ‘xyz’” from the popup that appears.
Post reply on HN