SQLite vs Postgres, timed on one machine

Users, subscriptions, and events, on SQLite and Postgres, both on one cloud VM. The single writer is in the numbers.

By David · Published October 26, 2026 · 13 min read

When SQLite is enough

SQLite vs Postgres is a file against a server. It lives on the backend and stack hub. SQLite’s own when-to-use page says SQLite competes with fopen(), not with a client/server database. The same page calls 100,000 hits a day a conservative estimate, not a ceiling, and says SQLite has been demonstrated with 10 times that. That demonstration is theirs, from the SQLite site, not a number from this benchmark.

Use SQLite when all of these are true:

• The process that runs SQL is on the same machine as the file.
• Writes can take turns. WAL mode lets readers proceed while one writer appends. There is still one writer at a time, because there is one WAL file.
• A backup you can copy is enough. The backup API and VACUUM INTO are the documented ways to snapshot a live file. This post did not time either one.
• You do not already have a second service that must open the same database.

The default journal mode is a rollback journal. This benchmark switched to WAL and left synchronous at FULL, which read back as 2. Foreign keys are off unless you turn them on. We turned them on. Both engines then rejected an event whose user did not exist. A schema that only works because the check is off is not the schema you will migrate.

Where Postgres wins

Start on Postgres when another computer has to send SQL. SQLite’s when-to-use page says to pick a client/server engine if many clients hit the same database over a network. The file lock has to work on that network filesystem, and SQLite’s page says that is a poor bet. WAL mode has the same limit: every process using the database has to be on one host, because they share memory.

Start on Postgres when writers cannot queue. The same SQLite page says one writer at a time is fine when each write is short and the others can wait, and that a client/server engine handles more write concurrency than SQLite will. The measured version of that is below. On this VM, extra workers slowed SQLite. They made Postgres faster than its own one-worker run, up to four workers, and they never made Postgres faster than SQLite.

Postgres also wins the jobs this timing does not cover. Roles and grants. A dump you can restore on any Postgres, including Supabase, which is hosted Postgres. A connection string an assistant can query. The ContextBolt Postgres MCP page lists a read-only server and says the reference npm package is archived, so check that a maintained server fits before you rely on it. Adding one is the same workflow as adding an MCP server to Claude Code. Keep the password out of any file you commit, including a Claude MD file checked in at the project root.

One timed query did go to Postgres. The dashboard aggregate was 12.8 ms median on Postgres and 24.9 ms on SQLite. Five runs, warm cache, same rows. That is the result. It is not a reason to ignore the insert times above it.

Concurrency and writes

The single writer shows up when the row count stays fixed and the worker count goes up. 20,000 events, disjoint primary keys, a commit every 100 rows. The timer starts after each worker has its own connection. One worker is the same insert pattern with nobody else to wait for.

SQLite went 118.6 ms, then 166.5 ms, then 494.4 ms. Adding workers made it slower. That is the one-writer limit on this workload: the others wait, and the waiting costs more than it saves. Postgres went 774.5 ms, then 592.9 ms, then 779.6 ms. Four workers beat one worker. Eight workers, on a 4-CPU VM, did not beat four. The four-worker Postgres runs were the noisy set: 384.5 ms to 705.9 ms, median 592.9 ms. The eight-worker SQLite runs were noisy too: 295.7 ms to 702.8 ms, median 494.4 ms. The other concurrent rows sat much closer to their medians.

Read the absolute times as well as the shape. At eight workers SQLite’s median was still 494.4 ms and Postgres was 779.6 ms. On a local socket, the single writer did not make SQLite lose. It made extra writers a waste. A hosted Postgres, or a second app server writing at the same time, is a different measurement. This one is the local case.

SQLite write transactions used BEGIN IMMEDIATE, so the writer lock is taken at the start of each 100-row batch. busy_timeout was 60 seconds. No run hit that timeout, and both engines committed all 20,000 rows. The cent totals matched the formula.

Hosted options for a solo founder

The timings above are not a bill, and they are not these services. Prices below were read from the vendor pages on October 26, 2026.

Cloudflare D1 is Cloudflare’s managed database with SQLite’s SQL semantics. The D1 pricing page bills rows read, rows written, and storage. There is no charge for hours, and no egress charge. On the Workers Free plan: 5 million rows read a day, 100,000 rows written a day, 5 GB stored. The Workers Paid plan has a $5 a month minimum. On that plan D1 includes 25 billion rows read a month and 50 million rows written, then $0.001 per million rows read and $1.00 per million rows written. Storage past 5 GB is $0.75 per GB-month. A write to an indexed column counts as an extra row written, because the index is written too. D1’s overview says you can restore a database to any minute in the last 30 days. That restore is their feature. This benchmark did not call D1.

Turso publishes Free at $0: 100 databases, 5 GB, 500 million rows read a month, 10 million rows written, 3 GB of sync. Developer is $5.99 a month, or $4.99 a month billed yearly: unlimited databases, 9 GB, 2.5 billion rows read, 25 million rows written, 10 GB of sync. Overages are off unless you enable them. With overages off, crossing one limit blocks the databases even if the other meters are under the cap. Turso’s docs call the embedded engine SQLite compatible and advertise concurrent writes, and they describe Turso Cloud as the host for Turso and libSQL databases. That concurrent-writer claim is theirs. It was not part of this run. Do not copy the one-writer chart onto Turso.

Supabase is Postgres. Free is $0, with 500 MB of database, two active projects, and a pause after a week with no activity. Pro starts at $25 a month and includes a $10 compute credit, which covers one Micro instance (shared CPU, 1 GB of RAM, $10 before the credit). The worked bill at 1,000, 10,000, and 50,000 users, from the October 24 price list, is Supabase vs Firebase. The plan price on October 26 was still $25. The local Postgres in this post is not a Supabase Micro, and it does not include the network hop to one.

Neon is Postgres. The Free plan is $0: 100 CU-hours per project, 1 GB of Postgres storage per project, scale to zero after 5 minutes, and that suspend cannot be turned off on Free. Neon defines a CU as about 4 GB of RAM, plus CPU and SSD. Their own example: 0.25 CU for 4 hours is 1 CU-hour. Launch is pay for what you use, no monthly minimum: $0.106 per CU-hour and $0.35 per GB-month. Scale compute is $0.222 per CU-hour, with the same storage price. An invoice under $0.50 is not collected. A suspended compute accrues no CU-hours. This post did not run a query against Neon, so it does not turn those unit prices into a monthly total. The free tier next to Supabase, the Launch bill for 100 CU-hours, and the dump in both directions are in Neon vs Supabase. The ORM in front of that connection string, on one small schema, is Drizzle vs Prisma.

Migrating later

The script creates the same tables on both engines. That is the part that makes a later move boring: integer ids, text plans, a BIGINT timestamp both sides can store. A production Postgres schema often uses timestamptz instead. We did not, so the comparison would stay on the same values.

When you do move, stop the writers first. SQLite’s backup page documents two copy tools that do not require you to invent a format: the online backup API, which can copy while other connections keep using the file, and VACUUM INTO, which writes a vacuumed copy to a second file. The older technique is a shared lock, a file copy, then releasing the lock. Writers wait while that lock is held. This post did not time a copy.

Load the rows into Postgres with SQL or COPY. Then point the app at the connection string. The rows that surprise people are the ones SQLite accepted and Postgres will not: a column that holds both numbers and text, or a foreign key that was never enforced because the pragma was off. Turn the pragma on before you have a year of rows, not after.

D1 and Turso can take a SQLite file, on their terms, not on this benchmark’s clock. Supabase and Neon take Postgres. Leaving Supabase is a Postgres dump. That path, and what the backup does not include, is in the Supabase comparison above.

A decision checklist

That file is a cost. What those users pay you is a different number. How to calculate MRR is the monthly price of the subscriptions you still have, with trials, tax, and one-off fees left out.