PostgreSQL vs MySQL vs SQLite in 2026: Benchmarks from 1K to 10M Rows

Architecture: Three Very Different Approaches

PostgreSQL: The Feature Powerhouse

PostgreSQL uses Multi-Version Concurrency Control (MVCC) to handle concurrent reads and writes without locking. Its extension ecosystem is unmatched — PostGIS for geospatial, pgvector for embeddings, TimescaleDB for time-series. It supports advanced types like arrays, hstore, and JSONB natively.

The tradeoff: MVCC creates dead tuples that require regular vacuuming, and the process model (one OS process per connection) means connection pooling is essential at scale.

MySQL: The Battle-Tested Workhorse

MySQL's InnoDB engine provides ACID compliance with a clustered index architecture that makes primary key lookups extremely fast. Its replication story is mature — group replication, InnoDB Cluster, and read replicas are production-proven at companies like GitHub and Shopify.

MySQL 9.x has closed many gaps with PostgreSQL, including improved CTEs, window functions, and JSON support. But it still lacks PostgreSQL's extension model and advanced type system.

SQLite: The Embedded Contender

SQLite runs in-process with zero network overhead. WAL (Write-Ahead Logging) mode enables concurrent reads alongside a single writer. It stores everything in a single file, making backups trivial and deployments simple.

The 2025-2026 ecosystem shift is significant: Turso provides distributed SQLite with multi-region replication, Cloudflare D1 puts SQLite at the edge, and Litestream streams WAL changes to S3 for durable backups. SQLite is no longer just for mobile apps.

Benchmark Methodology

All benchmarks were run 5 times with the median reported. Caches were warmed before measurement. We tested at four dataset sizes: 1K, 100K, 1M, and 10M rows to capture how each database degrades (or doesn't) as data grows.

Read Performance: Queries per Second

Point lookups by indexed column (user_id), averaged across 60-second sustained runs.

Analysis: SQLite dominates read performance at small to medium datasets because there is no network round-trip and no protocol overhead. Every query is a function call in the same process. However, at 10M rows, PostgreSQL's query planner and buffer management start to pay off — SQLite's simpler planner makes less optimal decisions with large datasets and complex indexes.

MySQL's clustered index gives it a slight edge over PostgreSQL for simple point lookups at smaller sizes, but PostgreSQL overtakes it at 10M rows where its more sophisticated statistics and planner shine.

Range Queries (BETWEEN on indexed timestamp, returning 100 rows)

At 10M rows: PostgreSQL delivered 12,400 q/s, MySQL hit 10,800 q/s, and SQLite managed 8,900 q/s. PostgreSQL's MVCC and index-only scans give it a clear advantage for analytical range queries at scale.

Write Performance

Three workload types tested at the 1M row baseline.

Analysis: SQLite's single-writer limitation is real. With 8 concurrent writers, it cannot parallelize — writes are serialized through a single mutex. PostgreSQL and MySQL handle concurrent writes gracefully because they were designed for it.

MySQL's InnoDB is slightly faster for single-row operations due to its change buffer and efficient clustered index updates. PostgreSQL wins bulk inserts thanks to its COPY command, which bypasses the SQL parser entirely.

JSON Performance Comparison

All three databases now support JSON querying, but the implementations differ significantly. We tested extracting a nested field from a JSON column and filtering on it, across 1M rows where each row contains a ~500-byte JSON payload.

Analysis: PostgreSQL's JSONB is in a different league. The binary storage format means it doesn't need to re-parse JSON on every access. GIN indexes on JSONB paths make filtered queries nearly as fast as regular indexed lookups. MySQL's multi-valued indexes (added in 8.0) help but still can't match PostgreSQL's flexibility. SQLite's JSON support is functional but lacks indexing options — you can create generated columns as a workaround, but it's not as elegant.

Hosting Costs: Managed Options Compared

The cost story is clear: SQLite options are dramatically cheaper. Cloudflare D1 at $5/month with a generous free tier is hard to beat for edge-first applications. Self-hosted SQLite with Litestream on a $6/month VPS gives you a production-grade database with continuous backups to S3 — for less than a coffee.

For PostgreSQL, Neon's serverless model is compelling if your traffic is spiky — you pay for compute only when queries are running. Supabase bundles auth, storage, and edge functions into the price, making the $25/month reasonable for full-stack apps.

Feature Comparison

Developer Experience

ORMs and Tooling

All three databases have excellent ORM support in 2026. Prisma, Drizzle, and SQLAlchemy support all three. TypeORM and Sequelize cover PostgreSQL and MySQL. Drizzle ORM has emerged as the developer favorite for TypeScript projects — its type-safe query builder works identically across all three databases.

Migration Tooling

PostgreSQL and MySQL have mature migration ecosystems — Flyway, Liquibase, Prisma Migrate, and Drizzle Kit all work well. SQLite migrations are trickier because ALTER TABLE support is limited (you still cannot drop or rename columns inline in all cases). Drizzle Kit handles this by recreating tables behind the scenes, but it's worth knowing the limitation.

Local Development

This is where SQLite shines brightest. No Docker container, no service to start, no port conflicts. Your database is a file. For local development and testing, SQLite offers the fastest feedback loop. Many teams use SQLite locally and PostgreSQL in production — Drizzle and Prisma make this cross-database workflow practical.

// drizzle.config.ts — same schema, different drivers
import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  schema: './src/db/schema.ts',
  driver: process.env.NODE_ENV === 'production' ? 'pg' : 'better-sqlite3',
  dbCredentials: process.env.NODE_ENV === 'production'
    ? { connectionString: process.env.DATABASE_URL! }
    : { url: './local.db' },
});

The SQLite Revolution: When Embedded Beats Client-Server

The most surprising finding from our benchmarks is not that SQLite is fast for small datasets — everyone knows that. It is that SQLite remains competitive up to 1 million rows for read-heavy workloads, while costing a fraction of a managed PostgreSQL or MySQL instance.

The 2026 SQLite ecosystem has solved the three historical objections:

• "SQLite can't replicate" — Turso provides multi-region replication with embedded replicas. Litestream continuously streams WAL changes to S3, GCS, or Azure Blob Storage. LiteFS enables read replicas across Fly.io nodes.
• "SQLite can't handle concurrent writes" — True, but BEGIN CONCURRENT (in development) will allow multiple writers. Until then, Turso's architecture handles write distribution. And for most web apps, a single writer at 11K writes/sec is more than enough.
• "SQLite isn't production-grade" — SQLite is the most deployed database in the world. Every iPhone, Android device, and web browser uses it. Cloudflare D1 runs millions of SQLite databases in production. The tooling has caught up to the engine's reliability.

The use cases where embedded SQLite wins are expanding rapidly:

• Edge computing: Cloudflare D1 puts your database within 50ms of every user on Earth
• Single-tenant SaaS: One SQLite database per customer eliminates noisy neighbor problems
• Read-heavy APIs: Embedded reads with zero network latency beat any managed database
• Serverless functions: No connection pool to manage, no cold-start connection penalty

Final Verdict: Recommendations by Use Case