3 ms·
To be fair they also say > Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite.
by dukeyukey 3mo ago
To be fair they also say
> Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite.
- inigyou 3mo agoSo 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 3mo agoThe 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 3mo agoAdding 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 2mo agoWhat exactly is wrong about a solution that perfectly fits the most common use case out there, at a fraction of the cost/complexity?
- simonw 3mo agoSQLite can happily handle thousands of reads and writes per second even on modest hardware.
- dukeyukey 3mo agoThey also say it seems to work well up to 500k a day, which is quite a bit.
- noxer 3mo agoI have 8+ million rows added daily to a 100+GB DB. There is a limit somewhere but I haven't found it yet.
- noxer 3mo agoI 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 3mo agoSo many problems in tech would be solved with $250 spent on an NVMe drive.