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.
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.