“SQLite is probably the only database you will ever need in most cases.”

That suggests that using anythin other than SQLite is singificantly more difficult or expensive and that’s not true. Pretty much every hosting company supplies dedicated database servers with builtin backups, failover etc. There is no need to run your own databases at all.

“Even if you start out small and later need to upscale, as long as your web application can run on the same machine as the database, which it can in 99% of the time,”

The fact that it has to run on the same machine disqualifies SQLite for larger scale operations. Sure, you can move everything to a faster, larger server, but as soon as you hit any serious size you’ll want to eliminate the single-server plan because it is a really really bad idea. really bad, like… bad.

“You can split up your database into multiple separate databases, and you can even give each user his/hers own database on the server.”

Literaly every other database engine can do this though… you’re not showing advantages of SQLite, just odd database designs, which might suggest that they are workarounds for shortcomings in SQLite….

I get the feeling that this article was written either by someone who really really likes SQLite, or someone who has never had any good experiences with any other databases and that may simply be that it’s not their thing, that’s fine, database administration is a niche and not everybody likes it no matter how simple it is. But both colour the article to a level that I don’t think it’s that useful, it’s a promo that suggests problems that don’t really exists and tries to plug advantages that aren’t real advantages.

Again; I’m not saying that SQLite is bad, but this article defends it in an odd way.

Even if your one server can handle all the traffic you get, it’s still a single point of failure, and this is a major problem if you want to provide some decent availability with your service. In fact, a lot of issues that will bring a server down will come up at the early stages of development, when you don’t actually have a lot of traffic. This problem is also dependent on the complexity of the application, and the number of paths to failure.

Another issue is tooling. Most SQL tools try to connect over the network to your db. This allows you to query/inspect any db environment you might have (e.g. dev, staging, prod). If you want to inspect your sqlite environment using third-party tooling, you now have to expose it to the network somehow. This is one more service on that host (which is what you’d have if you were running postgres or mysql in the first place).

All these issues can be (and are being) addressed (see rqlite, bedrock) but then why not just go with postgres from the start?

Having said all that, I am actually really looking forward with playing with sqlite because I hear the best things from multiple directions.