SQLite handled 315M daily requests on a laptop

A single SQLite file backed a social network with 50,000 users, 1,000,000 posts, 2,498,799 follows, and 4,999,764 likes—all in 343MB—and still served the app’s heaviest page at 3,654 requests per second on an Apple M1 laptop.

That benchmark comes from DB Pro’s test app, Chirp, which used Node 22, better-sqlite3, and SQLite 3.49.2. Every table was set to STRICT, and the backend ran as one Node process talking directly to chirp.db, with no separate database server.

Over real HTTP with 50 concurrent connections, the results looked like this:

• GET /post/:id: 51,427 req/s
• GET /u/:handle: 47,776 req/s
• GET /timeline/:id: 3,543 req/s
• Mixed workload with 95% timeline reads, 5% writes: 3,654 req/s

The heavy timeline query joins follow relationships against posts, sorts by time, and counts likes. DB Pro says that works out to roughly 315 million requests a day for the toughest endpoint.

Under raw query benchmarks, SQLite was even faster, including 232,011 ops/s for point reads and 23,459 committed write transactions per second for inserting a post. Batched inserts reached 32,217 rows/s.

Recommended reading

Russia’s cloud GPU demand jumps 507% on AI workloads

WAL mode made the biggest difference

The article’s main argument is that old complaints about SQLite locking mostly describe the rollback journal mode, not Write-Ahead Logging. In tests with seven reader threads running timeline queries alongside a writer:

• In WAL mode, reads stayed at 2,792 reads/s with 1,000 writes/s, with 4.40ms p99 latency and zero SQLITE_BUSY errors.
• In DELETE journal mode, the same setup dropped to 497 reads/s, with 133.85ms p99 and worst-case reads hitting 794ms.

With a writer running flat out, WAL still delivered 2,854 reads/s, while DELETE mode fell to 227 reads/s.

Where SQLite stops being enough

The post is clear about the limits. Once writes begin, reads stop scaling cleanly because commits invalidate memory-mapped pages and warm cache advantages fall away. The clean read-only figure of 17,581 reads/s dropped to about 2,800 reads/s in mixed workloads.

There are bigger architectural limits too:

• One writer globally: writes queue rather than run in parallel
• One machine: no automatic failover or replicas
• Less suitable for teams needing analytics over hundreds of millions of rows, many contending writers, or extension-heavy Postgres features

DB Pro also estimated performance on low-cost cloud instances, arguing that this workload is mostly constrained by single-core speed and enough RAM to keep the database in page cache. Its lowest-end estimate, a DigitalOcean Basic 1 vCPU / 2GB box at around $12/month, still came out to roughly 110 million timeline requests a day.

The practical advice is simple: favor fast single-core performance, enough RAM to hold the database, and local NVMe—not network-attached storage.

The post’s broader point is less about SQLite than startup engineering habits: many small apps provision Postgres long before they have enough traffic to justify the complexity. For DB Pro, the safer default is blunt: “Ship the file.”