Choosing a database is one of the earliest architectural decisions you’ll make — and one of the hardest to reverse. PostgreSQL, SQLite, and MySQL each represent a distinct philosophy about how data should be stored, queried, and scaled. This guide breaks down where each one shines so you can pick the right tool without second-guessing yourself six months in.

If you’re already weighing relational vs. non-relational options, start with our SQL vs NoSQL breakdown first.

The One-Sentence Pitch

• PostgreSQL — The feature-rich, standards-compliant powerhouse built for complex production workloads.
• SQLite — A zero-config, embedded database that lives inside your application as a single file.
• MySQL — The battle-tested workhorse behind millions of web apps, optimized for read-heavy traffic.

Quick Comparison Table

Feature	PostgreSQL	SQLite	MySQL
Type	Client-server RDBMS	Embedded / file-based	Client-server RDBMS
License	PostgreSQL (MIT-like)	Public domain	GPL v2 / Commercial
Best For	Complex queries, analytics, GIS	Mobile apps, CLI tools, prototypes	Web apps, CMS, read-heavy APIs
Concurrency	MVCC — excellent	Limited (file-level locking)	Good (InnoDB row-level locking)
JSON Support	Native JSONB with indexing	Basic JSON1 extension	Native JSON type
Full-Text Search	Built-in, configurable	FTS5 extension	Built-in (InnoDB)
Replication	Streaming, logical	Litestream / LiteFS	Primary-replica, group replication
Max DB Size	Unlimited (practical)	281 TB (theoretical)	Unlimited (practical)
Managed Hosting	Neon, Supabase, RDS, Crunchy	Turso, Cloudflare D1	PlanetScale, RDS, Vitess
Pricing	Free / managed from ~$0	Free / managed from ~$0	Free / managed from ~$0

Use Cases

PostgreSQL

Postgres is the default choice for production applications that need correctness, extensibility, and advanced data types. It handles JSONB, arrays, hstore, geospatial data (PostGIS), and time-series workloads without bolting on external systems. If your app involves complex joins, window functions, CTEs, or row-level security, Postgres handles it natively.

Common fits: SaaS platforms, fintech, analytics dashboards, multi-tenant apps, anything with a complex data model. Check our PostgreSQL cheat sheet for a quick syntax reference.

SQLite

SQLite isn’t a toy — it’s the most deployed database engine in the world. It runs inside your process with zero network overhead, making it ideal for mobile apps, desktop software, IoT devices, CLI tools, and local-first architectures. In 2026, the “SQLite on the edge” movement (Turso, Cloudflare D1, LiteFS) has turned it into a legitimate option for read-heavy web apps too.

Common fits: Electron apps, mobile backends, embedded systems, prototyping, single-server web apps, edge computing.

MySQL

MySQL powers a massive chunk of the internet. WordPress, Shopify’s early stack, and countless PHP/Laravel/Rails apps run on it. It’s optimized for straightforward read-heavy workloads and has a mature replication story. The InnoDB engine provides ACID compliance and row-level locking that handles moderate write concurrency well.

Common fits: content sites, e-commerce, legacy enterprise apps, LAMP/LEMP stacks. For a deeper head-to-head, see our PostgreSQL vs MySQL comparison.

Performance

Read performance — All three are fast for typical OLTP reads. SQLite wins on single-user latency because there’s no network hop. MySQL’s query optimizer is tuned for simple lookups and performs well with proper indexing. Postgres can be slightly slower on trivial queries but excels once complexity increases.

Write performance — Postgres and MySQL both handle concurrent writes well through different locking strategies. SQLite uses a single-writer model (WAL mode helps readers, but only one writer at a time), which becomes a bottleneck under concurrent write pressure.

Analytical queries — Postgres dominates here. Parallel query execution, advanced indexing (GIN, GiST, BRIN), and a sophisticated cost-based optimizer make it the clear winner for complex aggregations and reporting.

Scalability

Vertical scaling — All three benefit from more RAM and faster disks. Postgres and MySQL can leverage dozens of CPU cores. SQLite is inherently single-process, so vertical scaling has diminishing returns.

Horizontal scaling — MySQL has the most mature sharding ecosystem (Vitess, ProxySQL). Postgres supports logical replication and read replicas, with tools like Citus for distributed workloads. SQLite doesn’t scale horizontally in the traditional sense, though Turso’s libSQL fork and LiteFS offer creative replication patterns for edge deployments.

Connection handling — Postgres benefits from connection poolers like PgBouncer or Supavisor. MySQL handles connections natively with less overhead. SQLite has no connection concept — it’s in-process.

Hosting & Operations

PostgreSQL has the richest managed hosting landscape in 2026. Neon offers serverless Postgres with branching. Supabase bundles it with auth, storage, and realtime. AWS RDS and Aurora remain enterprise staples. Self-hosting is straightforward with solid community tooling (pgBackRest, Patroni).

SQLite requires almost no operations when embedded. For web deployments, Turso provides a managed libSQL service with edge replication, and Cloudflare D1 embeds SQLite into Workers. Self-hosting means managing a file — backups are literally cp database.db backup.db (or use Litestream for continuous streaming to S3).

MySQL is available on every major cloud. PlanetScale (built on Vitess) offers serverless MySQL with branching and schema migrations. AWS RDS, Google Cloud SQL, and Azure Database for MySQL are all mature. Self-hosting is well-documented but requires more tuning than SQLite.

Ecosystem & Tooling

PostgreSQL — Rich extension ecosystem (PostGIS, pgvector, TimescaleDB, pg_cron). First-class support in every major ORM (Prisma, Drizzle, SQLAlchemy, ActiveRecord). Strong community around Supabase and Neon.

SQLite — Supported by every programming language’s standard library. The better-sqlite3 Node.js driver is synchronous and fast. Drizzle and Prisma both support it. Limited extension ecosystem compared to Postgres, but the built-in feature set covers most needs.

MySQL — Massive legacy ecosystem. Every hosting provider supports it. Excellent tooling (MySQL Workbench, phpMyAdmin, Percona Toolkit). Strong ORM support, though some ORMs treat it as a second-class citizen behind Postgres.

If you’re also evaluating document databases, our MongoDB cheat sheet covers the NoSQL side of the equation.

Pricing

All three are open source and free to self-host. Managed pricing varies:

• PostgreSQL — Neon’s free tier includes 0.5 GB storage. Supabase offers 500 MB free. RDS starts around $15/month for the smallest instance.
• SQLite — Turso’s free tier includes 9 GB storage across edge replicas. D1 offers 5 GB free. Self-hosted cost is effectively zero.
• MySQL — PlanetScale’s Scaler plan starts at $39/month (they removed the free tier). RDS pricing mirrors Postgres. Self-hosted cost is effectively zero.

For hobby projects and prototypes, SQLite and Postgres (via Neon/Supabase) are the most cost-effective starting points.

When to Pick Each

Pick PostgreSQL when:

• You need advanced data types (JSONB, arrays, geospatial)
• Your queries involve complex joins, CTEs, or window functions
• You want a single database that can handle OLTP and light analytics
• You’re building a SaaS product or multi-tenant system
• You need row-level security or fine-grained access control

Pick SQLite when:

• Your app is single-user or low-concurrency
• You want zero operational overhead
• You’re building a mobile app, CLI tool, or desktop application
• You’re prototyping and want to move fast
• You’re deploying to the edge and need local reads

Pick MySQL when:

• You’re working with an existing MySQL codebase or CMS (WordPress, etc.)
• Your workload is read-heavy with simple query patterns
• You need mature, battle-tested replication out of the box
• Your team already has MySQL expertise
• You’re running a LAMP/LEMP stack

The Bottom Line

There’s no universally “best” database — only the best fit for your constraints. In 2026, the default recommendation for new projects leans toward Postgres for its versatility, with SQLite as a surprisingly capable option for simpler architectures. MySQL remains the pragmatic choice when compatibility and ecosystem matter more than cutting-edge features.

Start with the simplest option that meets your requirements. You can always migrate later — but you probably won’t need to if you choose deliberately now.