3 ms·

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 o

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 https://sqlite.org/mostdeployed.html

mr_toad 4mo ago
That’s a comprehensive list of single user devices.
- ibejoeb 4mo ago
  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 4mo ago
  '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 4mo ago
    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 4mo ago
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 4mo ago
  SQLite is good for read-concurrency, not great for write-concurrency.
  - simonw 4mo ago
    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.
    - zarzavat 4mo ago
      Exactly, people confuse "doesn't scale" with "is a bottleneck". There's many applications whereby hitting the limits of SQLite is either a physical impossibility, or implies that the application has achieved success such that replacing SQLite is the least of anyone's problems. I visited a piano store once that was running everything off MS Access. If only they had switched to HA technologies, they would be able to sell millions of pianos a day!
ksd482 4mo ago
levkk is talking about concurrency. The list you gave doesn't explain high concurrency requirements for usage.
- rpdillon 4mo ago
  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.
  - sieabahlpark 4mo ago
    [dead]
- DANmode 4mo ago
  Why doesn’t each of your users have a SQLite database writing up to a main? You can have as many as you want - and one is often plenty.
petcat 4mo ago
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".
- Rohansi 4mo ago
  SQLite is able to handle tens of thousands of write transactions per second on modern hardware. That is probably similar to or more than your real, multi-user, concurrent RDBMS.
  - andersmurphy 4mo ago
    Hundreds of thousands*
slashdave 4mo ago
I mean... if you count flat files as "databases", there are a heck of a lot more

mr_toad 4mo ago

That’s a comprehensive list of single user devices.

ibejoeb 4mo ago
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 4mo ago
'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 4mo ago
  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 4mo ago

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 4mo ago
SQLite is good for read-concurrency, not great for write-concurrency.
- simonw 4mo ago
  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.
  - zarzavat 4mo ago
    Exactly, people confuse "doesn't scale" with "is a bottleneck". There's many applications whereby hitting the limits of SQLite is either a physical impossibility, or implies that the application has achieved success such that replacing SQLite is the least of anyone's problems. I visited a piano store once that was running everything off MS Access. If only they had switched to HA technologies, they would be able to sell millions of pianos a day!

ksd482 4mo ago

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

rpdillon 4mo ago
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.
- sieabahlpark 4mo ago
  [dead]
DANmode 4mo ago
Why doesn’t each of your users have a SQLite database writing up to a main? You can have as many as you want - and one is often plenty.

petcat 4mo ago

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".

Rohansi 4mo ago
SQLite is able to handle tens of thousands of write transactions per second on modern hardware. That is probably similar to or more than your real, multi-user, concurrent RDBMS.
- andersmurphy 4mo ago
  Hundreds of thousands*

slashdave 4mo ago

I mean... if you count flat files as "databases", there are a heck of a lot more