[dukeyukey]

To be fair they also say

> Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite.

[noxer]

I have a 100GB SQLite DB in use that gets 8+ million rows added dally. It's on an off-the-shelf nvme SSD in a "server" that I build from 5+ year old parts.

Those are writes not hits so not directly comparable.

[maccard]

So many problems in tech would be solved with $250 spent on an NVMe drive.

[inigyou]

So about one per second (up to ten, less conservatively). I concur. But if you think your site might ever scale beyond that, do yourself a favor and use Postgres from the get-go.

[rafabulsing]

The vast, vast majority of websites never see anything even close to that, so it's a safe bet unless you have some specific reason to expect it to reach that kind of traffic, or you are dealing with workloads that SQLite really does not handle well, e.g. many concurrent writes. And if your workload is mostly reads, then you probably can use a cache layer, which allows SQLite to go further still.

[maccard]

Adding a cache layer to keep using the wrong database is an architecture failure - if you use Postgres from the get go you will not need the cache until way way later on anyway. (Side note, I’m team MySql but the same point applies)

[rafabulsing]

What exactly is wrong about a solution that perfectly fits the most common use case out there, at a fraction of the cost/complexity?

[simonw]

SQLite can happily handle thousands of reads and writes per second even on modest hardware.

[dukeyukey]

They also say it seems to work well up to 500k a day, which is quite a bit.

[noxer]

I have 8+ million rows added daily to a 100+GB DB. There is a limit somewhere but I haven't found it yet.