4 ms·
SQLite is optimized for frequent reads, but not frequent writes. When SQL writes data, it does table-level locking; i.e. the whole table is inaccessible to any
by blacksqr 5y ago
SQLite is optimized for frequent reads, but not frequent writes.
When SQL writes data, it does table-level locking; i.e. the whole table is inaccessible to any other write until the current write is complete. This is in contrast to e.g. Postgres, which does row-level locking; i.e. only the row currently being written is locked.
Still, SQLite is likely to be satisfactory for all but very high-load sites.
- ozzythecat 5y agoYou can’t do concurrent writes to SQLite, from what I understand. And as you mentioned, at the table level and not just row level. If you have multiple writes, presumably you’d have to move them to a queue, maybe with a dedicated writer thread. Ops post mentions serializing, which probably is saying this same thing. I’ve only used SQLite for some hacking/toy applications, so not sure if others have more insight. Would love to learn. I do see some advantages with SQLite. I imagine back up is super easy - just copy the whole file.