3 ms·

SQLite is good when you’re mostly reading. For writing, the major drawback of SQLite is it doesn’t support concurrent writes. All filesystems do (at least whe

SQLite is good when you’re mostly reading. For writing, the major drawback of SQLite is it doesn’t support concurrent writes. All filesystems do (at least when writing different files), all full-fledged RDBMS-es do, even some embedded databases do (like ESENT). Yet, in SQLite only a single thread can write. Even embedded chips are multicore these days…

someonewhocar3s 9y ago
It does keep things /very/ simple. Treat every core as a node, and enjoy scaling across devices?
justinclift 9y ago
Some work seems to be ongoing for improving SQLite concurrency: https://www.sqlite.org/cgi/src/timeline?n=100&r=begin-concurrent https://www.sqlite.org/cgi/src/timeline?n=100&r=begin-concur... Also mentioned here: https://news.ycombinator.com/item?id=12742943 https://news.ycombinator.com/item?id=12742943
JBReefer 9y ago
Isn't that because SQLLite's whole use case is "simple, small, fast database that competes with fopen() and not Postgres"? At least in my experience on NTFS, unless you know the section that 2 threads are writing to, and that section is different, you can't write to a file concurrently (N.B.: in C#) I'd be happy to be wrong (seriously that would make my day if someone could explain a clean way to do the above) but if I want to get "big boy database features" then I'd use a heavy database like SQL Server. I think it's great that there's an option like SQLLite out there for rapid prototyping and "store all your music metadata" type applications!
- Const-me 9y ago
  > simple, small, fast database that competes with fopen() and not Postgres" The hardware evolved in a way so even very small systems (phones, embedded, Raspberry Pi and other IoT devices) are now multi core. Multithreading is required to benefit from a multi-core CPU. For IO-heavy tasks, it’s sometimes a good idea to implement multi-threaded IO as well. > you can't write to a file concurrently I can concurrently write different files. Or to different streams/blobs/records for most other IO methods, except SQLite.

someonewhocar3s 9y ago

It does keep things /very/ simple. Treat every core as a node, and enjoy scaling across devices?

justinclift 9y ago

Some work seems to be ongoing for improving SQLite concurrency: https://www.sqlite.org/cgi/src/timeline?n=100&r=begin-concurrent https://www.sqlite.org/cgi/src/timeline?n=100&r=begin-concur... Also mentioned here: https://news.ycombinator.com/item?id=12742943 https://news.ycombinator.com/item?id=12742943

JBReefer 9y ago

Isn't that because SQLLite's whole use case is "simple, small, fast database that competes with fopen() and not Postgres"? At least in my experience on NTFS, unless you know the section that 2 threads are writing to, and that section is different, you can't write to a file concurrently (N.B.: in C#) I'd be happy to be wrong (seriously that would make my day if someone could explain a clean way to do the above) but if I want to get "big boy database features" then I'd use a heavy database like SQL Server. I think it's great that there's an option like SQLLite out there for rapid prototyping and "store all your music metadata" type applications!

Const-me 9y ago
> simple, small, fast database that competes with fopen() and not Postgres" The hardware evolved in a way so even very small systems (phones, embedded, Raspberry Pi and other IoT devices) are now multi core. Multithreading is required to benefit from a multi-core CPU. For IO-heavy tasks, it’s sometimes a good idea to implement multi-threaded IO as well. > you can't write to a file concurrently I can concurrently write different files. Or to different streams/blobs/records for most other IO methods, except SQLite.