The Stack Exchange link is incorrect about -ite being etymologically derived from lithos, as one of the commenters there noted. Maybe a misunderstanding of this wiktionary note or similar:

> But by the Hellenistic period, both the masculine -ίτης (-ítēs) and the feminine -ῖτις (-îtis) became very productive in forming technical terms for products, diseases, minerals and gems (adjectives with elliptic λίθος (líthos, “stone”)), ethnic designations and Biblical tribal names.

The meaning of that is not that -ite is etymologically derived from lithos. It’s trying to say that mineral names like “hematite” (αἱματίτης - literally “blood-red”) are originally adjectives agreeing with an implied noun lithos.

From the horse's mouth (Hipp's): "I wrote SQLite, and I think it should be pronounced "S-Q-L-ite". Like a mineral. But I'm cool with y'all pronouncing it any way you want. :-)"

Me, I say "sequeLITE" with the emphasis on the last syllable, but now I'm thinking of switching to "SEQuelite". You'll never catch me pronouncing it "ess-cue-ell" either way dammit!

:)

Sqlite is a bad fit for anything where ephemeral storage is the default. On the other hand is you use a simple VPS there is no problem.

There are multiple simple ways of doing SQLite backups https://sqlite.org/lang_vacuum.html#vacuuminto https://sqlite.org/rsync.html - or just lock and copy the file.

If you need to scale enough that it is a concern, then its not a good fit for your use case.

This is the way. I used to do the same way back in my ASP (not dotnet) days, only with SQL Server. Hosting the db alongside the app server turned out great, even though you’re always advised against it.

Cool, I've used Dokku similarly, but I'll usually still reach for a dbms myself a lot of the time. I have used SQLite when I need something portable, just not so much for an application that I'm containerizing anyway.

Been following the Cloudflare features with interest along the way... currently have a pretty good size VPS I've been using.

> I don't really understand the current trend of using sqlite in place of a traditional database. It has it's place, I use it in a client side project and it's really great

I think its more about the issue that databases like postgres are too much "magic". With Sqlite you see your database file, its a physical something. You want to move it to another server, its just a copy action, no dump/restore. You want to "upgrade", there is no mess like with postgres.

You want to create client separation, ... its just a file per client.

> although even there I have to be aware of the one writer only limitation.

The writer limit has not been a limit forever. You can easily do 20k writes per second, what is way beyond what most system anyway. You want 100k? A slightly different access pattern and voila. You want 1 million ... There are ways around it. If you put Sqlite vs Postgres for instance, ironically, seen Sqlite winning against postgres despite that single writer.

The whole hands on "we know what file is, where it is, and how to gain access to it" is really amazing. The whole "do not need to think about how to secure it on the network" also helps a lot.

Do i use Sqlite in production? No ... Postgres its extension support just rules. But i see the appeal for many.

I’ve been using SQLite for a lot of my backends since way before it’s cool. Back then I was frowning at all the people/tutorials spinning up MySQL/Postgres/heaven forbid Mongo for 1 read per second, 1 write per 10 seconds projects.

Now I’m frowning at people doing all sorts of gymnastics to beat SQLite into shape.

It’s always the same, people without a mind of their own looking at blog posts from cool kids and deciding they have to do it themselves too (not all the adopters of course, but most of them).

For a serious web project it's hard to imagine picking SQLite, unless you're using a proper "serverified" SQLite service like Turso or Cloudflare D1. I'd think zero-downtime deployments alone would be a dealbreaker for many. Then there's high-availability and horizontal scaling.

I love that SQLite lets me run the app locally with no "setup". And so I actually kinda like Turso and D1 for bridging the gap. I can have the best of both worlds: no setup, AND primetime-ready deployment.

All databases are painful in their own way. I've used all three at various times in my career, and I think SQLite behaves quite predictably, which has made it a lot easier for me personally to administrate.

If I had to start something new, I'd use SQLite until at least high 5 digit queries per second. Maybe more.

Even with very small number of requests - what happens when you have two concurrent ones?

Easy and useful, usually the basic is better.

I ever plan do it with sqlite, loading it at memory during app start and flush data to s3 during runtime but it create more corner cases and logic to handle.

Sqlite has always been the default database for Rails, even though it probably hasn't been the most common deployment choice.

Kind of but not really. Rails has defaulted to creating a project with an SQLite database in development for awhile now. But the expectation has always been you move to what you need.

SQLite has simply become "good enough" for production. So now you can take that dev default and simply deploy it for apps of a certain size and category if you want.

The way they got multi-writer working is a bit too adventurous for me.

It involves fiddling the database header to ensure you can keep track of the read-set from the VFS layer, by convincing SQLite to drop its page cache at the start of every transaction.

Other than that, a MVCC VFS is relatively straightforward. Here's an in-memory experiment if a few hundred lines of Go: https://github.com/ncruces/go-sqlite3/blob/v0.29.0/vfs/mvcc/...

I haven't settled on what's a good storage layer for something like this.

Neat! From a high level what's the difference between litebase and Turso?