I agree. Most uses of databases definitely don't need to grow larger than, say, a single filesystem, or a single application, or a single host, or a single network, or a single geographical region, or a single customer, or a single organization, or a single global network of customers in organizations in regions on networks on hosts on applications on filesystems.
There could not be any features of any other database that SQLite might not have, or that an application might need, or want.
We definitely should not, like, read a book on databases, or read the manual of another database, or something else crazy like that. There's no reason we might learn about other databases. They are just "shiny stuff", meaning, there's something going on with them that I can't see, because of all the glare.
Honestly, the existence of all those other databases, and database models, and the billions of dollars spent on them, is a fluke, probably. It's unlikely you will ever in your life see or work on an application that needs a database other than SQLite. Because the only applications you will ever work on won't ever run on more than one virtual host, or be used by more than one application. And definitely you will probably not need a feature that isn't in SQLite.
SQLite is very fast, it is very simple, it is very well written, and it has a lot of tests. Therefore we can conclude that you should never look at or learn about another database, because considering the previously states information, we know that no other database could possibly be desired or needed.
I don't know a lot about databases. And, granted, I only just found out about SQLite. But I am quite sure I am correct that SQLite is the only one you'll ever need in most cases.
I don't think this characterization of SQLite advocates is fair. I've written pet database systems from scratch, studied CS theory at university--including databases, worked for big, famous tech companies.
Looking back on my long career, I can say that literally every application I've ever worked on-- with one exception-- could have been run on a single modern machine, probably with SQLite as a backing store. I'm not sure, but there's a pretty good case that such a design would have improved things a fair bit.
The network was never our problem. The hardware turned out to not be the cause of any of our outages. Outages were always caused by a software bug or a misconfiguration of our complex applications. These misconfigurations were in large part caused by avoidable complexity. The complexity was often due to us trying to solve for scale and reliability problems that we didn't really have.
You can easily host multiple customers or organizations in any database. That's not something that SQLite or SQL Server or Postgres helps or hinders.
Very few of us ever work on a Google or Facebook scale-- even though we think we do.
Anyway, in my career, the one exception I can think of was a big-data application that really did need many servers just to store the actual petabytes of data. Even there, though, we could probably have partitioned the data across SQLite instead of Elastic and probably done alright.
All of that said, I run Postgres in production like a sane person, because I don't want to have to deal with managing a database. Render manages it for me so that I can focus on reading Hacker News. So, this entire rant is moot.
I bet most non-FAANG programmers have indeed never worked on an application which could not be built on a single host with SQLite. And SQLite is in fact more fully featured in some ways than some client-server DBs (when will Postgres add support, even via a plugin, for primary indexes?)
I agree with you that it is important to realize where a client-server DB may be needed, but the it really almost never is.
For perspective, same conversation, but different subject:
"A bicycle is all the transportation you will ever need in most cases.
I bet most non-bicycle drivers have indeed never been anywhere which couldn't have been gotten to by bike. And the bike is in fact more fully featured in some ways than some cars (when will cars shrink down? not require fuel? not pollute? cause less harm?)
I agree it's important to realize when a car may be needed, but in reality it almost never is."
Even if all of that is true... I still want to use a car, for good reasons. I may not need it, and it's more complex to use and maintain. But I get enough value from it that it's worth it.
There could not be any features of any other database that SQLite might not have, or that an application might need, or want.
We definitely should not, like, read a book on databases, or read the manual of another database, or something else crazy like that. There's no reason we might learn about other databases. They are just "shiny stuff", meaning, there's something going on with them that I can't see, because of all the glare.
Honestly, the existence of all those other databases, and database models, and the billions of dollars spent on them, is a fluke, probably. It's unlikely you will ever in your life see or work on an application that needs a database other than SQLite. Because the only applications you will ever work on won't ever run on more than one virtual host, or be used by more than one application. And definitely you will probably not need a feature that isn't in SQLite.
SQLite is very fast, it is very simple, it is very well written, and it has a lot of tests. Therefore we can conclude that you should never look at or learn about another database, because considering the previously states information, we know that no other database could possibly be desired or needed.
I don't know a lot about databases. And, granted, I only just found out about SQLite. But I am quite sure I am correct that SQLite is the only one you'll ever need in most cases.