undefined | Better HN

0 pointsDaycrawler8y ago0 comments

Unless you want to scale. I'm all for the rule of least power, but as soon as the app is exposed to multiple users I would ask and be sure about the expected number of simultaneous users before going with SQlite instead of going with a Client/Server RDBMS. Still, the bound is pretty high if you keep your transactions short.

0 comments

geocar8y ago

If you have the correct architecture, multiple users shouldn't matter at all-- I have used SQLite to store and query activity data with something like 10k concurrent "users" without difficulty on a single machine.

I am beginning to suspect that MySQL, PostgreSQL, DB2, Oracle, BigTable, and others allow one to get so far with the wrong architecture, that maybe some even very experienced programmers believe that to go faster they have no choice but more threads.

cousin_it8y ago

Can you describe the right architecture?

ngrilly8y ago

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

hasenj8y ago

SQLite supports concurrent reads and writes since 2010 with the introduction of the "write ahead log"

https://sqlite.org/wal.html

1 more reply

j / k navigate · click thread line to collapse