Hacker News Reader

Comment by Const-me | Hacker News Reader

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…

View on HN

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!

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

Some work seems to be ongoing for improving SQLite concurrency:

https://www.sqlite.org/cgi/src/timeline?n=100&r=begin-concur...

Also mentioned here:

https://news.ycombinator.com/item?id=12742943

Reply on news.ycombinator.com