PostgreSQL vs MySQL 2026: Which Should You Use?

When MySQL stops being enough

A common story: a startup runs happily on MySQL 8.0 for years, right up until it doesn't. The product had grown to include flexible user preferences stored as JSON, location-based search for nearby vendors, and an AI recommendation engine that needed vector similarity queries. MySQL could technically handle the JSON part (with workarounds). The geospatial stuff was painful. Vector search was simply off the table.

A migration like that can take weeks: converting schemas, rewriting raw queries, updating ORM configurations, and chasing subtle differences in how the two databases treat things like case sensitivity and GROUP BY strictness. Once the team is on PostgreSQL with PostGIS and pgvector, though, it usually moves noticeably faster, because features that would have needed separate services or awkward workarounds now worked natively.

PostgreSQL isn't always better. There are plenty of teams where MySQL is the right call and switching would waste everyone's time. Picking a database is one of those choices that haunts you for years. Switch too late and you're staring at weeks of migration pain; pick the wrong one early and every sprint goes into working around limitations that shouldn't exist.

Both databases have changed a lot. MySQL 9.x brought features PostgreSQL developers used to smugly point at as missing. PostgreSQL 17 pushed further on performance and developer experience, in ways that feel almost unfair. And the cloud ecosystem around both has matured to the point where managed hosting takes away half the operational headaches.

I don't want to hand you a generic "it depends," so I'll go through every major comparison point with real queries, benchmarks, and my opinions. By the end you should be able to make a confident choice, or at least an informed one.

Core philosophy and architecture

PostgreSQL: feature-rich and opinionated

PostgreSQL calls itself "the world's most advanced open-source relational database," and I think the claim holds up. It was designed from the start for correctness and extensibility. The MVCC (Multi-Version Concurrency Control) implementation is solid, the type system is very flexible, and extensions let you bolt on capabilities that would need entirely separate systems with other databases.

Standards compliance is a big part of it. If the SQL standard defines a behavior, PostgreSQL probably implements it correctly. That sounds academic until you're writing complex queries and want the same results in every environment.

MySQL: the speed-first workhorse

MySQL went another way. It was originally tuned for read-heavy web workloads and put speed and simplicity ahead of feature completeness. InnoDB (default since MySQL 5.5) added transactional safety and crash recovery, but the DNA is still "get the data fast."

MySQL 9.x has narrowed the feature gap a lot. Window functions, CTEs, JSON improvements, and better optimizer decisions make it a competitive choice for complex workloads too. The philosophy still leans toward keeping things simple and fast instead of supporting every edge case in the SQL standard, and for plenty of applications that's exactly right.

JSONB support, where PostgreSQL still dominates

Almost everyone works with semi-structured data in 2026, so this comparison matters a lot.

PostgreSQL JSONB

PostgreSQL's JSONB type stores data in a decomposed binary format, which means you get indexing, partial updates, and sophisticated querying on top of plain JSON validation.

-- Create a table with JSONB
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  attributes JSONB NOT NULL DEFAULT '{}'
);

-- Insert with nested JSON
INSERT INTO products (name, attributes) VALUES
  ('Laptop', '{"brand": "Dell", "specs": {"ram": 16, "storage": "512GB SSD"}, "tags": ["work", "portable"]}');

-- Query nested values
SELECT name, attributes->'specs'->>'ram' AS ram_gb
FROM products
WHERE attributes @> '{"brand": "Dell"}';

-- GIN index for fast JSON queries
CREATE INDEX idx_products_attrs ON products USING GIN (attributes);

-- Partial update without rewriting the whole document
UPDATE products
SET attributes = jsonb_set(attributes, '{specs,ram}', '32')
WHERE name = 'Laptop';

The @> containment operator with a GIN index is very fast. You can query deeply nested JSON without scanning the whole table, and jsonb_set, jsonb_insert, and the path-based operations let you change one part of a document and leave the rest alone.

MySQL JSON

MySQL added JSON support in 5.7 and has improved it since. It still feels bolted on.

-- Create a table with JSON
CREATE TABLE products (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  attributes JSON NOT NULL
);

-- Insert JSON data
INSERT INTO products (name, attributes) VALUES
  ('Laptop', '{"brand": "Dell", "specs": {"ram": 16, "storage": "512GB SSD"}, "tags": ["work", "portable"]}');

-- Query nested values
SELECT name, JSON_EXTRACT(attributes, '$.specs.ram') AS ram_gb
FROM products
WHERE JSON_CONTAINS(attributes, '"Dell"', '$.brand');

-- Generated column + index (workaround for indexing)
ALTER TABLE products
ADD COLUMN brand VARCHAR(100) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(attributes, '$.brand'))) VIRTUAL,
ADD INDEX idx_brand (brand);

The biggest limitation is that MySQL has no equivalent of a GIN index over a whole JSON document. You index JSON through generated columns, functional indexes (8.0.13+) or multi-valued indexes on JSON arrays (8.0.17+), and each of those only covers the specific paths you define in advance. PostgreSQL's GIN index covers the entire JSONB document automatically.

My verdict: PostgreSQL wins clearly for JSON-heavy workloads. If your app keeps user preferences, product catalogs, or any flexible-schema data in JSON, PostgreSQL will save you a lot of headaches later.

Full-text search

PostgreSQL full-text search

The built-in full-text search in PostgreSQL is surprisingly capable, with stemming, ranking, phrase search, and custom dictionaries.

-- Add a tsvector column
ALTER TABLE articles ADD COLUMN search_vector tsvector;

-- Populate it
UPDATE articles SET search_vector =
  setweight(to_tsvector('english', title), 'A') ||
  setweight(to_tsvector('english', body), 'B');

-- Create a GIN index
CREATE INDEX idx_articles_search ON articles USING GIN (search_vector);

-- Search with ranking
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('english', 'postgresql & performance') AS query
WHERE search_vector @@ query
ORDER BY rank DESC;

Is it as good as Elasticsearch? No. For many applications it's good enough, and you skip the operational work of running a separate search cluster. My guess is that most small-to-medium apps don't need Elasticsearch at all, because PostgreSQL's full-text search handles more than people expect.

MySQL full-text search

MySQL has had FULLTEXT indexes for a long time, and they work reasonably well for basic cases.

-- Create a fulltext index
ALTER TABLE articles ADD FULLTEXT INDEX idx_search (title, body);

-- Boolean mode search
SELECT title, MATCH(title, body) AGAINST('postgresql performance' IN BOOLEAN MODE) AS relevance
FROM articles
WHERE MATCH(title, body) AGAINST('postgresql performance' IN BOOLEAN MODE)
ORDER BY relevance DESC;

It's simpler to set up and less flexible. Weighting different columns isn't easy, the stemming is more basic, and phrase search is limited next to PostgreSQL's tsquery syntax.

So PostgreSQL gives you more control and better results here, while MySQL is the simpler option if your needs are basic.

CTEs and window functions

Common Table Expressions (CTEs) and window functions are table stakes for modern SQL. Both databases support them now, with small differences in the implementations.

Recursive CTEs

-- Works in both PostgreSQL and MySQL
-- Find all subcategories of a parent category
WITH RECURSIVE category_tree AS (
  SELECT id, name, parent_id, 1 AS depth
  FROM categories
  WHERE parent_id IS NULL

  UNION ALL

  SELECT c.id, c.name, c.parent_id, ct.depth + 1
  FROM categories c
  JOIN category_tree ct ON c.parent_id = ct.id
)
SELECT * FROM category_tree ORDER BY depth, name;

Both handle this well in 2026. MySQL's CTE support arrived in version 8.0 and is now mature and performant. PostgreSQL has had CTEs since version 8.4, and they're heavily optimized, particularly in PostgreSQL 12+, where the optimizer can inline non-recursive CTEs.

Window functions

-- Running total and ranking — both databases
SELECT
  employee_name,
  department,
  salary,
  SUM(salary) OVER (PARTITION BY department ORDER BY salary DESC) AS running_total,
  RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS salary_rank,
  LAG(salary) OVER (PARTITION BY department ORDER BY salary DESC) AS prev_salary
FROM employees;

PostgreSQL supports a wider range of window frame specifications and ships more built-in window functions. MySQL covers the common cases and occasionally falls short on complex frame definitions. In everyday queries you won't notice much difference.

Replication and high availability

PostgreSQL replication

Streaming replication is PostgreSQL's main HA mechanism. A standby server connects to the primary and replays WAL (Write-Ahead Log) records in near real time. On top of that:

• Synchronous replication guarantees zero data loss, at the cost of latency.
• Logical replication allows selective table replication, cross-version replication, and multi-directional setups.
• Patroni is the go-to tool for automated failover in self-managed setups.
• Read replicas that can serve queries are supported out of the box.

MySQL replication

MySQL gives you several replication modes:

• Asynchronous replication (the default) is fast but risks data loss on failover.
• Semi-synchronous replication waits for at least one replica to acknowledge before commit.
• Group Replication / InnoDB Cluster is MySQL's answer to automated HA, with consensus-based failover.
• MySQL Router handles connection routing in InnoDB Cluster setups.

Both are capable. InnoDB Cluster is arguably easier to set up for basic HA, and PostgreSQL's logical replication gives you more room for complex topologies. If you're on a managed cloud service, most of these differences get abstracted away anyway.

Performance benchmarks

Benchmarks depend heavily on hardware, configuration and schema, so treat any single set of numbers with suspicion and test your own workload (pgbench and sysbench are the usual tools). The general pattern in published comparisons looks like this:

MySQL edges ahead on simple reads and bulk inserts, since InnoDB is highly optimized for those patterns. PostgreSQL leads on complex queries, JSON operations, and high-concurrency writes, thanks to an MVCC implementation that avoids lock contention.

For most web applications, though, both are fast enough. The database won't be your bottleneck. Your ORM generating terrible queries will be. And for truly hot data you should put a Redis caching layer in front of either one, because that's where the big performance gains come from.

Extensions, PostgreSQL's secret weapon

This is where PostgreSQL pulls away from MySQL entirely. Extensions add capabilities that would normally need separate infrastructure.

Extensions worth knowing

• PostGIS is the gold standard for geospatial data. Location queries, proximity search, geographic analysis: PostGIS turns PostgreSQL into a GIS database. MySQL has basic spatial support, but PostGIS plays in a different league.
• pgvector does vector similarity search for AI/ML embeddings, so you can store and query vectors in your main database instead of running a separate vector database. With HNSW and IVFFlat indexes it handles millions of vectors efficiently.
• pg_cron schedules jobs inside the database, with no external cron or job scheduler.
• TimescaleDB turns PostgreSQL into a time-series database with automatic partitioning, continuous aggregates, and compression.
• Citus is distributed PostgreSQL for horizontal scaling, sharding your tables across multiple nodes transparently.

-- pgvector example: similarity search for AI embeddings
CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)  -- OpenAI embedding dimension
);

-- Create HNSW index for fast approximate nearest neighbor search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Find 5 most similar documents
SELECT content, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;

MySQL has no equivalent extension system. You can write UDFs (User-Defined Functions) and plugins, but that ecosystem is nowhere near as rich. I'd call this the single biggest difference between the two databases in 2026, especially now that AI features are becoming standard in web apps.

Cloud offerings in 2026

The managed database market has exploded, and often the cloud platform you like ends up deciding the database.

PostgreSQL cloud options

• AWS RDS for PostgreSQL / Aurora PostgreSQL is the enterprise standard. AWS markets Aurora as delivering several times the throughput of standard PostgreSQL, with automatic storage scaling.
• Supabase is the "Firebase alternative" built on PostgreSQL. You get auth, real-time subscriptions, edge functions, and a REST API out of the box, and the developer experience is phenomenal.
• Neon is serverless PostgreSQL with branching, so you can create database branches like Git branches. I love it for development workflows and preview environments.
• On Vercel, Postgres now comes through the Marketplace (Neon and others), since Vercel moved its own Vercel Postgres databases to Neon in December 2024. It still integrates tightly with Next.js and Vercel's deployment platform.
• Tembo used to offer managed PostgreSQL with one-click extensions, but the company has since pivoted to AI agent tooling, so check its current status before picking it.

MySQL cloud options

• AWS RDS for MySQL / Aurora MySQL brings the same Aurora benefits and is rock-solid for MySQL workloads.
• PlanetScale is built on Vitess (the technology behind YouTube's MySQL). It offers branching, schema change management, and horizontal sharding, and the developer workflow is excellent.
• Google Cloud SQL is Google's managed MySQL with automated backups and HA.
• TiDB Cloud is a MySQL-compatible distributed database that handles massive scale without manual sharding.

ORM support: Prisma and Drizzle

Modern ORMs support both databases, but the experience differs.

Prisma

Prisma works beautifully with both PostgreSQL and MySQL, though some features are PostgreSQL-only:

// schema.prisma
datasource db {
  provider = "postgresql" // or "mysql"
  url      = env("DATABASE_URL")
}

model Product {
  id         Int    @id @default(autoincrement())
  name       String
  attributes Json   // Works with both, but PostgreSQL JSONB filtering is better
  createdAt  DateTime @default(now())
}

// Prisma JSON filtering — works best with PostgreSQL
const products = await prisma.product.findMany({
  where: {
    attributes: {
      path: ['brand'],
      equals: 'Dell'
    }
  }
});

Prisma's JSON filtering maps to PostgreSQL's native JSONB operators and falls back to less efficient approaches on MySQL. It looks like the Prisma team has prioritized PostgreSQL, which tells you something about where the ecosystem is heading.

Drizzle

Drizzle ORM has tighter database-specific integrations:

// Drizzle with PostgreSQL — uses native types
import { pgTable, serial, text, jsonb } from 'drizzle-orm/pg-core';

export const products = pgTable('products', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  attributes: jsonb('attributes').default({}),
});

// Drizzle with MySQL
import { mysqlTable, int, varchar, json } from 'drizzle-orm/mysql-core';

export const products = mysqlTable('products', {
  id: int('id').primaryKey().autoincrement(),
  name: varchar('name', { length: 255 }).notNull(),
  attributes: json('attributes'),
});

You get more control over database-specific features with Drizzle, which helps when you want to use everything PostgreSQL's JSONB or MySQL's specific optimizations offer.

When to use PostgreSQL

Pick PostgreSQL when:

• You need JSONB for flexible schema data with complex querying
• Your application requires geospatial queries (PostGIS)
• You're building AI features that need vector similarity search (pgvector)
• You want advanced SQL features like CTEs, window functions, lateral joins, and array types
• Data integrity and standards compliance are priorities
• You're using Supabase or Neon as your platform
• Your workload mixes complex analytical queries with OLTP

When to use MySQL

Pick MySQL when:

• You need maximum read throughput for simple queries
• Your team already has deep MySQL expertise
• You want PlanetScale's branching and schema management workflow
• Your application is a traditional CRUD app without exotic data types
• You're working with a WordPress, Laravel, or legacy PHP codebase
• Horizontal sharding is a near-term requirement (Vitess ecosystem)
• Your hosting environment only supports MySQL (shared hosting, some managed platforms)

Migration tips

Moving from MySQL to PostgreSQL is the more common direction, and these are the gotchas I'd watch for:

1. Auto-increment becomes SERIAL or IDENTITY. PostgreSQL uses sequences under the hood, and for modern PostgreSQL you should use GENERATED ALWAYS AS IDENTITY.
2. Backtick quoting becomes double quotes. MySQL quotes identifiers with backticks; PostgreSQL uses double quotes. Better still, don't use reserved words as column names at all.
3. GROUP BY is strict. PostgreSQL requires every selected column to be either in GROUP BY or inside an aggregate. MySQL's ONLY_FULL_GROUP_BY mode does the same, but many MySQL setups have it disabled.
4. PostgreSQL has a real BOOLEAN type. MySQL's BOOLEAN is just TINYINT(1).
5. String comparison differs. PostgreSQL is case-sensitive by default for = comparisons, while MySQL depends on the collation (often case-insensitive by default). This one bites teams repeatedly during migrations.
6. LIMIT syntax differs. Both support LIMIT, but MySQL's LIMIT offset, count form doesn't work in PostgreSQL. Use LIMIT count OFFSET offset instead, which works in both.

-- MySQL syntax
SELECT * FROM users LIMIT 10, 20;

-- PostgreSQL syntax (also works in MySQL)
SELECT * FROM users LIMIT 20 OFFSET 10;

pgloader can automate much of the migration, including schema conversion and data transfer. In the application code, search for backtick-quoted identifiers, MySQL-specific functions (IFNULL becomes COALESCE, GROUP_CONCAT becomes STRING_AGG), and any raw SQL. I'd also run your test suite against PostgreSQL early in the migration, since that catches most of the compatibility issues.

My recommendation

After years of working with both, my default is simple: start with PostgreSQL unless you have a specific reason not to.

The extensions (pgvector, PostGIS, TimescaleDB) let PostgreSQL grow with your application in ways MySQL can't match. JSONB alone saves you from running a separate document store for semi-structured data. And the PostgreSQL cloud ecosystem, with Supabase and Neon, is moving faster than the MySQL side.

MySQL is still a good choice, though. It's battle-tested at absurd scale (Facebook, Uber, YouTube via Vitess), and PlanetScale has done wonderful work on the developer experience. If your team knows MySQL deeply and your use case is straightforward CRUD, don't switch because PostgreSQL is trendier. Switching databases for bragging rights is a terrible use of engineering time.

The worst outcome is spending weeks debating databases instead of building your product. Both will serve you well for the vast majority of applications, so pick one, learn it deeply, and optimize when you hit real limitations rather than hypothetical ones.

If you're preparing for technical interviews, knowing when to pick PostgreSQL vs MySQL and explaining the trade-offs is a common part of system design interview preparation. Interviewers care more about the nuance in your answer than about which database you name.

Just don't use SQLite in production for a high-traffic, write-heavy multi-user web app. We need to draw the line somewhere.