That’s why there are billions of SQLite databases right?

SQLite is likely used more than all other database engines combined. Billions and billions of copies of SQLite exist in the wild. SQLite is found in:

Every Android device Every iPhone and iOS device Every Mac Every Windows 10/11 installation Every Firefox, Chrome, and Safari web browser Every instance of Skype Every instance of iTunes Every Dropbox client Every TurboTax and QuickBooks PHP and Python Most television sets and set-top cable boxes Most automotive multimedia systems Countless millions of other applications

https://sqlite.org/mostdeployed.html

▲

mr_toad 6 hours ago | parent | next [-]

That’s a comprehensive list of single user devices.

▲

ibejoeb 5 hours ago | parent | next [-]

Single-user, a single natural person, doesn't striclty mean single-accessor though. I don't think anyone here is suggesting that sqlite is a viable replacement a for any networked client/server postgresql system, but it is certainly capable of handling more than the most basic 1:1 tasks. Beyond that, the point is that you only need a file, so when you have natural data boundaries, a lot of problems decompose to that single user/single concern paradigm.

▲

larubbio 4 hours ago | parent | prev [-]

'production' doesn't equal 'multi-user concurrent access'. There are production uses where sqlite is a valid choice even if it may not be the best choice for multi-user production use cases.

	▲	therealdrag0 3 hours ago \| parent [-]
		strawman? I have seen a dozens of these debates and never once have I seen someone questioned the validity of it for embedded usecases.

▲

pibaker 5 hours ago | parent | prev | next [-]

GP calls out concurrency as a weakness of SQLite. Most of the examples here don't experience the same load even a moderately sized web service experience day to day.

And no, being a part of the python standard library doesn't means it is being used by the average python user. These days I'd say at least half of them are just there for machine learning.

▲

OutOfHere 3 hours ago | parent [-]

SQLite is good for read-concurrency, not great for write-concurrency.

	▲	simonw 3 hours ago \| parent [-]
		SQLite requires writes run sequentially. Most SQLite write operations take single digit milliseconds or even microseconds. If your writes are inexpensive (inserting or updating single small rows) you'll probably never even notice the queue.

▲

ksd482 5 hours ago | parent | prev | next [-]

levkk is talking about concurrency. The list you gave doesn't explain high concurrency requirements for usage.

	▲	rpdillon 5 hours ago \| parent [-]
		My read is that levkk is conflating concurrency with "real production apps" and this whole thread is starting to surface that "real production apps" and "high concurrency" are not measuring the same thing at all. Sqlite is used in real production apps more than any other database. Sqlite is also weak at any sort of write concurrency. Both can be true.

▲

petcat 5 hours ago | parent | prev [-]

sqlite is great for the contacts app on your phone, but that's it.

Hipp even said that it is not a replacement for a real multi-user, concurrent RDMS. Its primary competitor is "fsync".