That’s a comprehensive list of single user devices.
replySingle-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.
reply'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.
replystrawman? I have seen a dozens of these debates and never once have I seen someone questioned the validity of it for embedded usecases.
replylevkk is talking about concurrency. The list you gave doesn't explain high concurrency requirements for usage.
replyMy 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.
replySqlite 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.
[dead]
replyWhy doesn’t each of your users have a SQLite database writing up to a main?
replyYou can have as many as you want - and one is often plenty.
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.
replyAnd 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.
SQLite is good for read-concurrency, not great for write-concurrency.
replySQLite 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.
replyExactly, 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.
replyI 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!
I mean... if you count flat files as "databases", there are a heck of a lot more
replysqlite is great for the contacts app on your phone, but that's it.
replyHipp even said that it is not a replacement for a real multi-user, concurrent RDMS. Its primary competitor is "fsync".
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.
reply