81–85 of 85 posts
Earlier quoted context omitted.
How it that simplicity? To batch updates makes the code far more complex. To install any full strength DB is trivial. I don't get the 'simplicity'?
That depends entirely on what you're doing. If your workload is heavily transactional, then sure, that might add complexity. The simplicity is not having a separate process that can fail, and that requires fail over, and monitoring.
We're talking about concurrent writes. We're talking about batching inserts. Because SQLite can't handle a high throughput, so you batch a bunch of inserts together.
If the only way to get performance is to batch inserts, then you've got to write a whole load of manual queue code to queue up X number of inserts to insert them all at once.
Worse still, if your server crashes, bug, etc. you've just lost all those inserts. But you've already responded with 201s! So if you want any sort of guarantee, you've got to write even more code to cache them on disk or redis or something.
You're basically re-implementing features of postgre, badly, to make up for SQLite's deficiencies,
It really doesn't matter HOW you do it, it's the fact you have to do it at all. It's not simpler, it's more complicated. Installing/using a fully fledged DB is trivial these days.
Earlier quoted context omitted.
But n can be so big that it you never run into it. My company has a read-heavy SQLite-backed service that serves roughly 150,000 daily users with p99.9 at about 5 milliseconds. We did some rough projection and determined we could reach the total addressable market of our product in the US without even approaching having a problem.
How can your company guarantee p99.9 if there is only one instance? Is there any log shipping/duplication etc? Is consistency maintained on one server fault?
Honestly, 99.9% uptime is pretty generous - we can fit in quite a few catastrophes per year and still have 99.9% uptime. In the 2 years this service has been running, we've had 100% uptime via zero-downtime deployments, anyway.
In terms of monitoring, traces and error logs are shipped to our observability solution, yes.
Is there a similar effort for Django? Django Sqlite driver is slow and not tested for production.
It also seems to have the same concurrency issues as described in the article. At least from my experience the "database is locked" error appears quite often.
https://centraltrunks.blogspot.com/2022/07/django-sqlite-dat...
https://code.djangoproject.com/ticket/29280
(I authored the rant in the first link)