SQLite vs PostgreSQL vs MySQL

This page has no score column, and it never will. Every other comparison on toolweight ranks vendors selling roughly the same thing at different prices. These five are engines with different shapes: SQLite is a file format with a query planner attached, PostgreSQL is a process-per-connection MVCC server, MySQL and MariaDB are thread-per-connection MVCC servers tuned for replication, and DuckDB is a columnar analytics engine that happens to speak SQL. Weighting them against each other would produce a number that says more about the weights than the engines. So instead the table is descriptive, and the decision lives in prose.

PostgreSQL is the correct default for most teams, and the reason is boring: it has the widest SQL surface, the best extension ecosystem, and the most people who already know it. pgvector made it the default vector store too, which killed a whole category of standalone databases. What the marketing never mentions is the operational tax. Postgres is the heaviest engine here to run — that is the killer field on this page. Autovacuum tuning, transaction-ID wraparound, bloat, a process per connection so PgBouncer stops being optional past a few hundred clients, and major-version upgrades that mean pg_upgrade or a logical-replication cutover. Managed Postgres exists precisely because self-hosting it well is a job.

SQLite is the most under-used engine here and the most over-claimed by the people who love it. The claims are true: WAL mode gives many concurrent readers, and one machine with an NVMe disk serves an astonishing amount of traffic with zero network hops. The constraints get skipped: one writer at a time, no built-in replication, a twelve-step table rebuild for most schema changes beyond ADD COLUMN, and a backup story that means adopting Litestream or Turso. That is a straight trade, not a warning. One process, short writes, and you are buying a great deal of simplicity.

MySQL and MariaDB are still the right answer more often than the Postgres-shaped internet admits, for one specific reason: changing the schema of a very large table without taking writes offline. Online DDL, INSTANT ADD COLUMN, and a decade of gh-ost and pt-online-schema-change in production make that routine in a way it is not on Postgres. Thread-per-connection also forgives a badly behaved pool. Against that: a narrower SQL surface, a thin extension ecosystem, and a licence question. MySQL is GPLv2-or-commercial under Oracle, MariaDB is GPLv2 under a foundation. Shipping the server inside a product makes that difference the whole decision; running a website makes it noise.

The tree, then. Does more than one process write to this data concurrently? If no, and the working set fits on one disk, use SQLite and turn on WAL mode. If yes: does a meaningful share of your query load look like aggregation over columns rather than fetching rows by key? If so, that half of the workload belongs in DuckDB or a warehouse, not in your OLTP engine, and the remaining half is a smaller problem. Then: do you need extensions — pgvector, PostGIS, TimescaleDB — or window-heavy, CTE-heavy SQL? If yes, PostgreSQL, and budget for the operations. If no, and your actual fear is altering a 500 GB table without downtime, MySQL or MariaDB. If none of that discriminates, it is a genuine tie, and a tie means pick the engine somebody on the team has already debugged at three in the morning.

The first question is not which SQL dialect you prefer, it is whether the database is a library or a server. SQLite and DuckDB run inside your process: no daemon, no port, no credentials to rotate, no network hop, no connection pool, and no second thing to monitor. A query is a function call. That collapses an entire layer of your architecture, and the cost is that the database's availability is now your process's availability, and adding a read replica means shipping the file — Litestream, LiteFS, Turso — rather than pointing a replica at a primary.

Server engines charge you a daemon and pay you back with a network boundary. Several app instances, an analyst with psql, a read replica in another region, a bastion host, a migration that runs from CI rather than from whichever container won the race. The detail that catches teams out is the connection model. PostgreSQL forks a process per connection, so a thousand idle Lambda connections is a memory problem and PgBouncer stops being optional; MySQL and MariaDB use a thread per connection and are far more forgiving of a badly configured pool. If your compute is serverless and bursty, that difference matters more than any feature in the table.

SQLite in WAL mode gives you many concurrent readers and exactly one writer. Writes are serialised, so the arithmetic is simple: write transaction duration multiplied by writes per second must stay comfortably below one. Short transactions at a few hundred writes per second are fine on commodity hardware. Long transactions are what kill you, and holding a write transaction open across a network call is the classic way to turn a healthy app into a locked one.

MVCC engines let writers proceed in parallel by keeping old row versions, and then hand you the bill for those versions. On PostgreSQL it arrives as autovacuum, table and index bloat, and transaction-ID wraparound warnings. On InnoDB it arrives as undo-log growth and a history list length that climbs when a long-running read transaction refuses to end. Neither is hard once you know it exists; both are surprises the first time.

One concurrency detail deserves more attention than it gets: the default isolation levels differ. PostgreSQL defaults to READ COMMITTED, MySQL and MariaDB default to REPEATABLE READ, SQLite is effectively serialisable, and DuckDB gives snapshot isolation. Application code written against one engine's default can change behaviour silently on another — read-modify-write races that were impossible become possible, or vice versa. Port the isolation assumptions, not just the SQL.

PostgreSQL has the widest SQL surface here by a distance: lateral joins, materialised and non-materialised CTEs, partial and expression indexes, generated columns, exclusion constraints, window functions that keep gaining features, JSONB with GIN indexes, and an extension mechanism that turned it into a geospatial database, a time-series database and a vector database without forking. If your queries are analytical in shape but transactional in access pattern, this is the engine that will not run out of room.

MySQL and MariaDB trade surface area for a very fast primary-key path and predictable clustered-index behaviour. Most application queries are exactly that shape, which is why so much of the web runs on them. You feel the ceiling when the reporting queries arrive and someone starts writing five-way joins with correlated subqueries.

SQLite's planner is small and honest about it. It handles ordinary plans well, does less well on many-way joins, and has no parallelism — one query, one core. DuckDB inverts every one of these assumptions: vectorised columnar execution, multi-core by default, reads Parquet, CSV, S3 and live PostgreSQL tables directly, and will aggregate a billion rows on a laptop while your OLTP engine is still planning. The right architecture for many teams is not choosing between them but running two: rows in Postgres or SQLite, columns in DuckDB, over the same object storage.

There is no pricing group, because these engines are free and the money is entirely in who runs them. The comparison people need next — Neon against Supabase against RDS against Aurora, or PlanetScale and Vitess against managed MySQL — is a different page with different fields: cold start, branching, connection pooling, egress, backup retention, region coverage. Hosted-Postgres and hosted-MySQL are planned as their own categories for exactly that reason, and they will have score columns, because those are vendors selling the same thing at different prices.

Until then, the adjacent pages are the useful ones. Convex alternatives covers the layer above this decision, where the database, the API and the sync engine ship together and the engine choice is made for you. S3-compatible storage covers where the blobs go — the other half of every schema on this page, and the substrate DuckDB reads from. LLM APIs covers the retrieval side of the pgvector column, since the embedding model constrains dimensionality and therefore the index you can afford.

Every cell here comes from the engine's own reference manual rather than a vendor pricing page, which is why this is the best-sourced page on toolweight: these projects document their limits precisely and change them slowly. Where a claim is a judgement rather than a documented fact — extension ecosystem, migration tooling, client-library maturity, and the operational burden score — it is marked inferred and the ladder is spelled out in the column help so you can disagree with the placement rather than the number. Where a project genuinely documents no limit, the cell is null and renders as an em dash instead of a fabricated ceiling.

The killer field is operational burden, scored 1–5 where lower is better. It measures what a competent team must do to keep the engine healthy in production, not how hard it is to install: 1 is a file your process opens, 5 is a cluster with a full-time owner. It is the field that inverts the usual ranking — PostgreSQL has the strongest feature set on this page and the highest burden, and pretending otherwise is how teams end up with a vacuum problem eighteen months in. One finding is visible only by absence: SQLite appears nowhere in the timeline below. It ships several releases a year, all backwards compatible, and none of them change a decision. That stability is a feature and it does not generate news.