[chistev]

The SQLite documentation says that

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."

[Cthulhu_]

I remember this section for the 200 queries per page thing, which is a huge difference between sqlite and most databases. Most databases run in a separate process and use a network boundary to separate it from the server processes (socket connection or even http), which alone exacerbates the n+1 problem, and / or puts pressure on the amount of queries one should trigger per page view. SQLite doesn't care because it runs as part of the server process.