Comment by wokwokwok

What both articles are saying is that concurrent writes under a certain threshold or heavy read-only activity is perfectly acceptable usage pattern for sqlite in production.

...the problem here is that historically rails (and others) use deferred transactions and that causes sqlite to fail even under trivial load conditions without simply waiting for the db to free for the next write, because people who've written the drivers don't understand how to use sqlite.

If you use sqlite correctly under heavy load it's slow not unreliable.

> as long as your workload meets its feature set.

Sure... but to be fair that probably covers a lot of microservices and probably a lot of apps too.

Obviously as you scale, it won't, so sure, it's a limited use case... but, heck, I've seen dozens of microservices each with their 'own database' (ie. read same RDS, with different database instances) that all fail at once when that instance goes down. Woops.

Better? Worse?

Hm. Sqlite is insanely reliable. I like isolated reliable services.

It's not for everything, but nothing is... I think it's suitable for more use cases than you're giving it credit for.