Performs much better then postgres in terms of query latency which is ultra important for the domain we operate in.
I take machine level backups every 2 hours, so in the event of an outage, just boot the disk image on a new vm and it's off.
I would never do this on my professional job due to the stigma, but for this side project, it has been incredible
I love controversy so I was able to push SQLite through as the sole persistence mechanism for our product. Virtually every constraint lined up with our business perfectly.
We sell a B2B product that gets installed by our customers, so they love it too. No more sweaty hands conversations about why their database server cant talk to their application server over their networks while we are caught in the middle trying to avoid taking ownership of their internal IT problems.
> They’d double click on the thing and a dialog box would pop that says, “Can’t connect to database server,” and it wasn’t our fault. We didn’t have any control over the database server, but what do you do if you can’t connect to the server, so we got the blame all the same because we were painting the dialog box.
Using the right tool for the job does indeed carry a lot of stigma in many professional environments. Instead you use the tool that some VP has been sold by some salesman.
Because, serializing db access through a single process only becomes a problem when the number of reads/writes get so large, that the process becomes a bottlenec.
And judging by the test the author of the linked article did, that would have to be a HUGE number.
I presume that's block level backups? Or some snapshotting?
As far as I know, block level filesystem copies can get inconsistent (so we have journalling file systems). But assuming it works well, like a filesystem aware snapshot, can sqlite deal with files snapshotted in the middle of an operation?