sqlite
1,819 Requests per Second on a SQLite Database in the Backend
September 21, 2026 · 5 min read
Every infra vendor says their stack “scales.” We’d rather show you the run that proves it.
We ran the benchmark. We wrote down every number it produced. We’re publishing all of it here, including the parts that don’t flatter us.
What we tested
We pointed a load generator at our backend and fired 64 concurrent write requests at it for 30 seconds straight. It hit a SQLite-backed API endpoint the way a real client would: over HTTP, no shortcuts.
We didn’t run this on a beefy dev laptop to inflate the numbers. We ran it on hardware sized like our actual production server: 1 vCPU, 1 GiB of RAM.
Then we ran a second pass on 2 vCPUs, 1 GiB of RAM, to see what an extra core buys you. Both runs capped memory with no swap. A real problem would show up as an out-of-memory kill, not get quietly papered over.
The numbers
| Hardware | Concurrent requests | Writes/second | p50 latency | p95 latency | p99 latency | Error rate |
|---|---|---|---|---|---|---|
| 1 vCPU, 1 GiB RAM | 64 | 1,819 | 11.1 ms | 104.8 ms | 181.6 ms | 0% |
| 2 vCPUs, 1 GiB RAM | 64 | 3,493 | 9.5 ms | 62.2 ms | 90.6 ms | 0% |
Zero errors, on both runs. Not “low error rate.” Zero.
That’s 1,819 writes per second, sustained, on a single vCPU, against a SQLite-backed API, with p99 latency under 200ms. An extra core roughly doubles that.
Neither number is a lab trick. It’s the same 1 vCPU / 1 GiB class of machine we actually run in production.
What about a lot of apps running at once?
Throughput is half the story. Memory is the other half, because a backend that falls over at 50 tenants isn’t multi-tenant. It’s a demo.
We kept 200 apps alive simultaneously, each backed by its own SQLite file, inside a 1 GiB memory cap. Peak memory usage: about 787 MB. No out-of-memory kill, no crash.
| Metric | Value |
|---|---|
| Apps alive simultaneously | 200 |
| Peak memory (RSS) | ~787 MB |
| Memory cap | 1 GiB |
| Out-of-memory events | 0 |
That’s the number behind a claim we already make elsewhere: around 200 apps per 1 GiB of RAM. This benchmark is where that number comes from.
The honest caveat
We’re not going to pretend splitting work across more SQLite files always makes things faster. Our own numbers say otherwise on small hardware.
On a 1-2 vCPU machine, spreading the same load across more tenants didn’t multiply throughput. On a machine with a lot more cores to spare, it did.
That’s consistent with what we’ve said from the start. We’re not selling raw performance. We’re selling cost.
An idle app costs close to nothing, so one small server can hold hundreds of them. If you want the deeper argument for why SQLite handles this kind of write load in the first place, we wrote about that here: You don’t need a big database. SQLite alone is enough.
Try it yourself
These aren’t numbers from a slide deck. They’re from a backend you can sign up for right now, on the same class of hardware we tested.
FAQ
- Is 64 concurrent requests a realistic number, or a cherry-picked one?
- It's the concurrency level we tested end-to-end with zero errors, not a ceiling we're claiming. We picked it because it's a meaningful sustained load for a small-to-mid SaaS backend, and we ran it on the same hardware class we use in production, not an oversized dev machine.
- Does splitting an app across more SQLite files make it faster?
- Not automatically, and our benchmark shows that honestly. On small hardware (1-2 vCPUs), spreading load across more tenants didn't increase throughput. The benefit of one SQLite file per app isn't raw speed, it's isolation and cost: idle apps cost almost nothing, so a small server can host hundreds of them.
- What happens with more than 200 apps running at once?
- We measured up to 200 apps alive simultaneously inside a 1 GiB cap, with room to spare. We haven't published numbers past that point, so treat anything beyond 200 as an estimate, not a tested result.
