update
May 9, 2026
By Teun
SQLite benchmarks on Hetzner's cheapest VPS show real production load
A benchmark on Hetzner’s $4.99-per-month CX23 VPS tested SQLite with a 6 GB database that did not fit in RAM. The results showed about 3.9k operations per second for a mixed read/write workload, with the author saying SQLite handled real production-style traffic on the low-cost shared-CPU server.
A new benchmark from s13k.dev tested SQLite on Hetzner’s cheapest VPS, the CX23, priced at $4.99 per month. The setup used a 6 GB database on a machine with 3.7 GiB of RAM, so the database could not stay fully in memory and real disk I/O was involved.
The box was a shared-resource VPS with 2 vCPUs on Intel Xeon Skylake at 2.1 GHz, no swap, and a 38 GB ext4 disk configured with noatime and scheduler=none. The system ran Debian 13, and the test used SQLite 3.53.1 statically linked into a C benchmark.
The author said the database was configured with production-style pragmas rather than aggressive tuning. Those settings included WAL mode, synchronous=NORMAL, a page size of 8192, cache_size of 256 MiB, mmap_size of 256 MiB, temp_store=MEMORY, and a busy_timeout of 5000.
The author also called out one important limitation: synchronous=NORMAL is not durable in the strict ACID sense. According to the post, a power loss can roll back the last committed transactions still sitting in the WAL file, while corruption is the risk with synchronous=OFF; synchronous=FULL avoids that loss.
The benchmark compared two cases. One was a 1 million row database of about 246 MB, which fit comfortably in RAM. The other was a 10 million row database of about 6 GB, which exceeded RAM and forced reads to hit disk.
In the in-memory case, SQLite reached 124,123 inserts per second, 155,828 random primary-key selects per second, 58,239 indexed range selects per second, and 53,284 operations per second for a mixed 70% reads, 25% updates, 5% inserts workload. Concurrent reads across four threads hit 103,894 per second, while concurrent writes came in at 1,055 per second.
Once the working set outgrew RAM, performance dropped sharply on random reads. Random primary-key selects fell from 155,828 per second to 3,609 per second, a 43x drop, according to the benchmark table. Range scans, per-row updates, and the mixed OLTP workload also slowed by large margins.
On the 6 GB database, the mixed 70/25/5 workload reached 3,915 operations per second with p99 latency of 710 microseconds and p999 latency of 2.2 milliseconds. Concurrent reads across four threads reached 14,396 operations per second, while concurrent writes reached 3,305 per second.
The author said the write results looked counterintuitive at first. SQLite serializes writers, so only one write runs at a time, and when each write is very fast in RAM, the locking and thread-switching overhead becomes a bigger part of the total cost.
The post ends with the claim that SQLite can handle real production load on a cheap shared-CPU Hetzner VPS, including about 14 million operations per hour on the mixed workload and sub-3 millisecond tail latency.
