3 ms·
> You not only store files as blobs, you can also store a lot of metadata on top of them, and then, when your needs inevitably grow, start using other SQL table
by notyourday 7y ago
> You not only store files as blobs, you can also store a lot of metadata on top of them, and then, when your needs inevitably grow, start using other SQL tables for the rest of your application configuration or state. And it's all in one neat tidy package
That's a great solution in search of a problem for a small dataset.
For a large dataset it is a terrible solution, because disks fail and bit-rot happens. Ability to easily restore a tiny subset of data ( single file or multiple files ) using standard commands ( cp/rsync/etc ) is highly underappreciated.
- pdimitar 7y agoWhy of course. This entire discussion should always be complemented with the sqlite3's intended use cases. Even the authors admit it's not every app. So yes, definitely reach for a richer DB system when your needs grow beyond the point where sqlite3's weaknesses start to show. I believe the discussion in the entire HN thread is on the general topic of "is sqlite3 really that good for small-to-mid-sized projects", to which I believe the answer is definitely a yes.