You have to look where SQLite isn't rather than where it is these days.
cough _Billions_ cough with a capital "B". Very nearly every non-trivial electronic device built over the past 10-15 years. (Non-trivial being very roughly: "anything with a UI or having the potential to run one.")
completely off topic at this point, but Jim Cornette reading paid advertisements for codecademy was very funny during the pandemic. He insisted on pronouncing it code-cademy while his co-host tried to correct him.
Um, actually this[1] suggests that it originally wasn't about anything other than seeming like a good name and that any deeper explanation that has been given was made up. Of course, by the same token, "it seemed like a good name" could have also been made up. But it appears that the team eventually embraced it in the oxidization[2] sense.
[1] https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...
ad nauseam
Case in point: This discussion was originally about SQLite.
This was pre-WAL, presumably enabling WAL would help a lot (but is still not the default, so beware). But the caveats were real, it's not like people just took one look at the name and though "'SQLite?' I better put a big warning in our documentation to not use this in production."
Indeed it would!
"WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently."
https://www.sqlite.org/wal.html
I think the people advocating for SQLite to be used in more places are all assuming write ahead logging is enabled.
The chief problem that I see with WAL is that it breaks ACID with databases that are ATTACHed, as the documentation shows:
All the time. I suspect this is similar.
...I forgot how significant these problems are. These are quite serious.
"However, WAL mode has notable disadvantages. To accelerate searching the WAL, SQLite creates a WAL index in shared memory. This improves the performance of read transactions, but the use of shared memory requires that all readers must be on the same machine. Thus, WAL mode does not work on a network filesystem. It is not possible to change the page size after entering WAL mode. In addition, WAL mode comes with the added complexity of checkpoint operations and additional files to store the WAL and the WAL index."
https://vldb.org/pvldb/volumes/15/paper/SQLite%3A%20Past%2C%...
> By default, the configuration uses SQLite. If you’re new to databases, or you’re just interested in trying Django, this is the easiest choice. SQLite is included in Python, so you won’t need to install anything else to support your database. When starting your first real project, however, you may want to use a more scalable database like PostgreSQL, to avoid database-switching headaches down the road. [0]
SQLite is primarily embedded/local database and cannot be easily separated and shared over network [1] between multiple disposable backend/worker instances.
Then most hosting for rails were stateless, so you had no way of storing SQLite on disk.
And finally, for serious production you need high availability and SQLite couldn't offer that.
Edit: I looked into a common Go driver for SQLite[1] and the FAQ reads,
> Can I use this in multiple routines concurrently?
> Yes for readonly. But not for writable. See #50, #51, #209, #274.
Every time I see a blog post from fly.io reg SQLite I'm tempted to use it for my next project, But the need to rewrite my framework for limited data types and the doubts regarding concurrency keeps me away.
When SQLite arrived it got lumped in with file storage that can't scale. Rails only perpetuated what everyone was already thinking.
A friend of mine made a similar point about GIMP. I'd never thought about it that way. What a shame to be hindered by such a terrible name choice (in GIMP's case).
I think there has been a lot of recognition in the last 10 years that sqlite is actually quite robust, but it still hasn't been considered suitable for serious use is based on how software and database servers have traditionally operated.
It seems like what's changing that now is the recognition that other approaches may make more sense given modern software architecture.
As far as I can recall, it was always well regarded as an embeddable database. What makes you think that it wasn't taken seriously "for much of its lifetime"?
Been in missiles for a while.