<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1544383835-bda2bc66a55d?w=1200&amp;auto=format&amp;fit=crop"><h2 id="postgresql-17-vs-mysql-9-which-database-should-you-choose-in-2026">PostgreSQL 17 vs MySQL 9: Which Database Should You Choose in 2026?</h2>The PostgreSQL vs MySQL question has been asked thousands of times, and the internet is full of outdated answers. MySQL 5.7 advice is irrelevant when MySQL 9 is in production. Postgres 10 comparisons miss six major releases of improvements.This is the 2026 version of that comparison — based on the current releases, with a focus on what actually matters for teams building modern applications.Short answer: PostgreSQL wins on features and correctness; MySQL wins on simplicity and ecosystem familiarity. But the gap is narrower than it used to be, and the right choice depends on your specific needs.Let’s break it down.<img src="https://images.unsplash.com/photo-1518770660439-4636190af475?w=1000&amp;auto=format&amp;fit=crop" alt="Database Architecture"> Photo by Alexandre Debiève on Unsplash<hr><h2 id="current-versions-at-a-glance">Current Versions at a Glance</h2><table><thead><tr><th>&nbsp;</th><th>PostgreSQL 17</th><th>MySQL 9.2</th></tr></thead><tbody><tr><td>Released</td><td>Late 2024</td><td>2025</td></tr><tr><td>License</td><td>PostgreSQL License (permissive)</td><td>GPL / Commercial</td></tr><tr><td>ACID Compliance</td><td>✅ Full</td><td>✅ Full (InnoDB)</td></tr><tr><td>MVCC</td><td>✅ Yes</td><td>✅ Yes (InnoDB)</td></tr><tr><td>JSON Support</td><td>✅ Native JSONB</td><td>✅ Improved JSON</td></tr><tr><td>Full-Text Search</td><td>✅ Built-in</td><td>✅ Built-in (less capable)</td></tr><tr><td>Vector Operations</td><td>✅ pgvector extension</td><td>⚠️ Limited</td></tr><tr><td>Partitioning</td><td>✅ Mature</td><td>✅ Improved</td></tr></tbody></table><hr><h2 id="json-postgresql-still-leads-but-mysql-has-closed-the-gap">JSON: PostgreSQL Still Leads, But MySQL Has Closed the Gap</h2>PostgreSQL’s <code>JSONB</code> type has been the gold standard for document storage in a relational database. Binary storage, full indexing, rich operator set. MySQL 9’s JSON improvements are real but still trail.<h3 id="postgresql-jsonb-power-features">PostgreSQL JSONB Power Features</h3><div><pre><code>-- Powerful path queries with JSONPath (SQL/JSON standard)
SELECT *
FROM products
WHERE properties @@ '$.category == "electronics" &amp;&amp; $.rating &gt; 4.5';

-- GIN index on any JSON path
CREATE INDEX idx_props_category ON products 
USING GIN ((properties -&gt; 'category'));

-- JSON aggregation with complex transformations
SELECT 
 category,
 jsonb_agg(
 jsonb_build_object(
 'id', id,
 'name', name,
 'price', price
 ) ORDER BY price
 ) AS items
FROM products
GROUP BY category;

-- Update nested JSON without rewriting the whole object
UPDATE products
SET properties = jsonb_set(
 properties,
 '{specs, ram}',
 '"16GB"'
)
WHERE id = 123;
</code></pre></div><h3 id="mysql-9-json--significant-improvements">MySQL 9 JSON — Significant Improvements</h3>MySQL 9 added proper JSON schema validation and improved indexing via functional indexes on JSON paths:<div><pre><code>-- Functional index on JSON path (MySQL 9)
ALTER TABLE products
ADD INDEX idx_category ((CAST(properties-&gt;&gt;'$.category' AS CHAR(50))));

-- JSON schema validation (new in MySQL 9)
ALTER TABLE products
ADD CONSTRAINT valid_product_schema
CHECK (JSON_SCHEMA_VALID(
 '{"type": "object", "required": ["category", "sku"]}',
 properties
));

-- JSON_TABLE for treating JSON arrays as rows
SELECT jt.*
FROM products,
JSON_TABLE(properties-&gt;'$.tags', '$[*]'
 COLUMNS (tag VARCHAR(50) PATH '$')
) AS jt;
</code></pre></div>Verdict: PostgreSQL’s JSONB is still more capable (better indexing, richer operators, JSON path queries), but MySQL 9 is good enough for most use cases. If you’re building a system where JSON documents are central, PostgreSQL wins clearly. If JSON is occasional/supplemental, MySQL 9 is adequate.<hr><h2 id="performance-it-depends-heavily-on-workload">Performance: It Depends Heavily on Workload</h2>The “which is faster” question doesn’t have a universal answer. The pattern matters more than the database.<h3 id="read-heavy-simple-queries">Read-Heavy, Simple Queries</h3>MySQL historically wins on simple primary key lookups and single-table queries, largely due to its simpler query execution path and aggressive caching defaults.<div><pre><code>-- MySQL tends to be faster here at high QPS
SELECT * FROM users WHERE id = ?;
SELECT * FROM sessions WHERE token = ? AND expires_at &gt; NOW();
</code></pre></div>In benchmarks at 10,000 req/s for single-row lookups, MySQL typically shows 15-30% better throughput than PostgreSQL on identical hardware.<h3 id="complex-queries-joins-analytics">Complex Queries, Joins, Analytics</h3>PostgreSQL’s query planner is more sophisticated and consistently outperforms MySQL on complex joins, CTEs, and analytical queries.<div><pre><code>-- PostgreSQL handles this more efficiently
WITH user_stats AS (
 SELECT 
 user_id,
 COUNT(*) as order_count,
 SUM(total) as total_spent,
 AVG(total) as avg_order
 FROM orders
 WHERE created_at &gt; NOW() - INTERVAL '90 days'
 GROUP BY user_id
),
ranked AS (
 SELECT 
 u.*,
 us.*,
 RANK() OVER (PARTITION BY u.tier ORDER BY us.total_spent DESC) as tier_rank
 FROM users u
 JOIN user_stats us ON u.id = us.user_id
)
SELECT * FROM ranked WHERE tier_rank &lt;= 10;
</code></pre></div>Verdict: For OLTP with simple queries at very high throughput (social media feeds, session lookups), MySQL can edge out PostgreSQL. For anything analytically complex, PostgreSQL wins. For mixed workloads, PostgreSQL is the safer general-purpose choice.<hr><h2 id="vector-operations-postgresql-wins-by-a-lot">Vector Operations: PostgreSQL Wins by a Lot</h2>If you’re building any AI-powered features — semantic search, recommendations, RAG pipelines — this category may be decisive.PostgreSQL with <code>pgvector</code> is a mature, production-ready vector database:<div><pre><code>-- Install pgvector
CREATE EXTENSION vector;

-- Store embeddings
CREATE TABLE documents (
 id SERIAL PRIMARY KEY,
 content TEXT,
 embedding vector(1536) -- OpenAI text-embedding-3-small dimensions
);

-- Create HNSW index for fast approximate nearest neighbor search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Semantic similarity search
SELECT 
 id,
 content,
 1 - (embedding &lt;=&gt; $1::vector) AS similarity
FROM documents
ORDER BY embedding &lt;=&gt; $1::vector
LIMIT 10;

-- Hybrid search: vector similarity + keyword filter
SELECT id, content
FROM documents
WHERE category = 'technical'
 AND ts_rank(to_tsvector(content), plainto_tsquery('kubernetes')) &gt; 0.1
ORDER BY embedding &lt;=&gt; $1::vector
LIMIT 5;
</code></pre></div><code>pgvecto.rs</code> (Rust-based alternative to pgvector) pushes performance further with better index compression and GPU-accelerated operations.MySQL has no equivalent native vector search capability. You’d need to use a separate vector database (Pinecone, Weaviate, Qdrant) and manage the complexity of a polyglot persistence layer.Verdict: PostgreSQL wins decisively if vector search matters to you.<hr><h2 id="replication-and-high-availability">Replication and High Availability</h2><h3 id="postgresql">PostgreSQL</h3>PostgreSQL’s streaming replication is battle-tested and flexible. Logical replication (introduced in PG 10, mature in PG 17) enables:<ul><li>Partial replication (specific tables or rows)</li><li>Cross-version replication</li><li>Replication to non-PostgreSQL targets</li></ul><div><pre><code>-- Create publication on source
CREATE PUBLICATION my_pub FOR TABLE orders, products;

-- Create subscription on replica
CREATE SUBSCRIPTION my_sub
 CONNECTION 'host=primary-host dbname=mydb'
 PUBLICATION my_pub;
</code></pre></div>Tools like Patroni (automatic failover), pgBouncer (connection pooling), and Citus (horizontal sharding) are production-proven.<h3 id="mysql">MySQL</h3>MySQL’s GTID-based replication is reliable, and Group Replication (the foundation for InnoDB Cluster) provides multi-primary capabilities with automatic failover:<div><pre><code>-- InnoDB Cluster setup (via MySQL Shell)
-- Provides automatic failover without external tools
dba.createCluster('myCluster')
cluster.addInstance('user@host2:3306')
cluster.addInstance('user@host3:3306')
</code></pre></div>MySQL’s replication story has historically been stronger for cloud managed services — AWS RDS Multi-AZ, Aurora MySQL, Google Cloud SQL for MySQL are all very mature.Verdict: Roughly comparable, with MySQL having a slight edge in managed cloud environments due to more mature managed service offerings. PostgreSQL has caught up significantly with Amazon Aurora PostgreSQL and Google AlloyDB.<hr><h2 id="ecosystem-and-extensions">Ecosystem and Extensions</h2>PostgreSQL’s extension ecosystem is one of its biggest advantages:<table><thead><tr><th>Extension</th><th>What it does</th></tr></thead><tbody><tr><td><code>pgvector</code></td><td>Vector similarity search</td></tr><tr><td><code>PostGIS</code></td><td>Geographic data (the gold standard)</td></tr><tr><td><code>TimescaleDB</code></td><td>Time-series data</td></tr><tr><td><code>pg_cron</code></td><td>In-database cron jobs</td></tr><tr><td><code>Citus</code></td><td>Distributed PostgreSQL</td></tr><tr><td><code>pglogical</code></td><td>Advanced logical replication</td></tr><tr><td><code>pg_partman</code></td><td>Partition management</td></tr><tr><td><code>HypoPG</code></td><td>Hypothetical indexes for planning</td></tr></tbody></table><div><pre><code>-- pg_cron: run scheduled tasks in SQL
SELECT cron.schedule(
 'cleanup-old-sessions',
 '0 3 * * *', -- 3 AM daily
 'DELETE FROM sessions WHERE expires_at &lt; NOW() - INTERVAL ''7 days'''
);

-- PostGIS: geospatial queries
SELECT name, ST_Distance(location, ST_MakePoint(-73.9857, 40.7484))
FROM restaurants
WHERE ST_DWithin(location, ST_MakePoint(-73.9857, 40.7484), 0.01)
ORDER BY 2
LIMIT 10;
</code></pre></div>MySQL has fewer third-party extensions, but the community is active and the built-in features are comprehensive.<hr><h2 id="the-decision-framework">The Decision Framework</h2><img src="https://images.unsplash.com/photo-1519389950473-47ba0277781c?w=1000&amp;auto=format&amp;fit=crop" alt="Database Decision"> Photo by Marvin Meyer on UnsplashChoose PostgreSQL when:<ul><li>Complex queries and joins are common</li><li>You need vector search / AI features</li><li>Geospatial data is in scope</li><li>You value standards compliance (ANSI SQL, JSON/SQL standard)</li><li>You need flexible extensibility</li><li>Your team has PostgreSQL experience</li></ul>Choose MySQL when:<ul><li>You’re migrating from an existing MySQL codebase</li><li>Team expertise is already MySQL-oriented</li><li>You’re using a platform with tight MySQL integration (PlanetScale, Vitess)</li><li>Simple, high-throughput read workloads dominate</li><li>You need Group Replication’s built-in multi-primary support</li></ul>Either works fine for:<ul><li>Standard web application CRUD</li><li>Medium-scale transactional workloads</li><li>Cloud managed services (both have excellent managed offerings)</li></ul><hr><h2 id="summary">Summary</h2>The 2026 answer is more nuanced than “just use Postgres”:<ul><li>MySQL 9 is a genuinely good database that has closed many historical gaps. It’s not the MySQL 5.x of old. For teams with existing MySQL expertise or infrastructure, there’s no compelling reason to migrate.</li><li>PostgreSQL 17 remains the more capable system for complex workloads, and the ecosystem (pgvector, PostGIS, Citus) is unmatched. It’s the better default choice for new projects where the decision is open.</li><li>The AI feature gap is real. If you’re building anything with semantic search or vector similarity, PostgreSQL + pgvector is the pragmatic choice over managing a separate vector database.</li></ul>The PostgreSQL community’s momentum is stronger — the pace of feature development, the growth of the extension ecosystem, and the quality of managed cloud options (Aurora PostgreSQL, AlloyDB, Neon, Supabase) make it the safer long-term bet.But “safer bet” doesn’t mean MySQL is a bad choice. Pick the one your team can operate well. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

PostgreSQL 17 vs MySQL 9: Which Database Should You Choose in 2026?
The PostgreSQL vs MySQL question has been asked thousands of times, and the internet is full of outdated answers. MySQL 5.7 advice is irrelevant when MySQL 9 is in production. Postgres 10 comparisons miss six major releases of improvements.
This is the 2026 version of that comparison — based on the current releases, with a focus on what actually matters for teams building modern applications.
Short answer: PostgreSQL wins on features and correctness; MySQL wins on simplicity and ecosystem familiarity. But the gap is narrower than it used to be, and the right choice depends on your specific needs.
Let’s break it down.
Photo by Alexandre Debiève on Unsplash
Current Versions at a Glance
 
 PostgreSQL 17
 MySQL 9.2
 
Released
 Late 2024
 2025
 
License
 PostgreSQL License (permissive)
 GPL / Commercial
 
ACID Compliance
 ✅ Full
 ✅ Full (InnoDB)
 
MVCC
 ✅ Yes
 ✅ Yes (InnoDB)
 
JSON Support
 ✅ Native JSONB
 ✅ Improved JSON
 
Full-Text Search
 ✅ Built-in
 ✅ Built-in (less capable)
 
Vector Operations
 ✅ pgvector extension
 ⚠️ Limited
 
Partitioning
 ✅ Mature
 ✅ Improved
 
JSON: PostgreSQL Still Leads, But MySQL Has Closed the Gap
PostgreSQL’s JSONB type has been the gold standard for document storage in a relational database. Binary storage, full indexing, rich operator set. MySQL 9’s JSON improvements are real but still trail.
PostgreSQL JSONB Power Features
-- Powerful path queries with JSONPath (SQL/JSON standard)
SELECT *
FROM products
WHERE properties @@ '$.category == "electronics" && $.rating > 4.5';
-- GIN index on any JSON path
CREATE INDEX idx_props_category ON products 
USING GIN ((properties -> 'category'));
-- JSON aggregation with complex transformations
SELECT 
 category,
 jsonb_agg(
 jsonb_build_object(
 'id', id,
 'name', name,
 'price', price
 ) ORDER BY price
 ) AS items
FROM products
GROUP BY category;
-- Update nested JSON without rewriting the whole object
UPDATE products
SET properties = jsonb_set(
 properties,
 '{specs, ram}',
 '"16GB"'
)
WHERE id = 123;
MySQL 9 JSON — Significant Improvements
MySQL 9 added proper JSON schema validation and improved indexing via functional indexes on JSON paths:
-- Functional index on JSON path (MySQL 9)
ALTER TABLE products
ADD INDEX idx_category ((CAST(properties->>'$.category' AS CHAR(50))));
-- JSON schema validation (new in MySQL 9)
ALTER TABLE products
ADD CONSTRAINT valid_product_schema
CHECK (JSON_SCHEMA_VALID(
 '{"type": "object", "required": ["category", "sku"]}',
 properties
));
-- JSON_TABLE for treating JSON arrays as rows
SELECT jt.*
FROM products,
JSON_TABLE(properties->'$.tags', '$[*]'
 COLUMNS (tag VARCHAR(50) PATH '$')
) AS jt;
Verdict: PostgreSQL’s JSONB is still more capable (better indexing, richer operators, JSON path queries), but MySQL 9 is good enough for most use cases. If you’re building a system where JSON documents are central, PostgreSQL wins clearly. If JSON is occasional/supplemental, MySQL 9 is adequate.
Performance: It Depends Heavily on Workload
The “which is faster” question doesn’t have a universal answer. The pattern matters more than the database.
Read-Heavy, Simple Queries
MySQL historically wins on simple primary key lookups and single-table queries, largely due to its simpler query execution path and aggressive caching defaults.
-- MySQL tends to be faster here at high QPS
SELECT * FROM users WHERE id = ?;
SELECT * FROM sessions WHERE token = ? AND expires_at > NOW();
In benchmarks at 10,000 req/s for single-row lookups, MySQL typically shows 15-30% better throughput than PostgreSQL on identical hardware.
Complex Queries, Joins, Analytics
PostgreSQL’s query planner is more sophisticated and consistently outperforms MySQL on complex joins, CTEs, and analytical queries.
-- PostgreSQL handles this more efficiently
WITH user_stats AS (
 SELECT 
 user_id,
 COUNT(*) as order_count,
 SUM(total) as total_spent,
 AVG(total) as avg_order
 FROM orders
 WHERE created_at > NOW() - INTERVAL '90 days'
 GROUP BY user_id
),
ranked AS (
 SELECT 
 u.*,
 us.*,
 RANK() OVER (PARTITION BY u.tier ORDER BY us.total_spent DESC) as tier_rank
 FROM users u
 JOIN user_stats us ON u.id = us.user_id
)
SELECT * FROM ranked WHERE tier_rank <= 10;
Verdict: For OLTP with simple queries at very high throughput (social media feeds, session lookups), MySQL can edge out PostgreSQL. For anything analytically complex, PostgreSQL wins. For mixed workloads, PostgreSQL is the safer general-purpose choice.
Vector Operations: PostgreSQL Wins by a Lot
If you’re building any AI-powered features — semantic search, recommendations, RAG pipelines — this category may be decisive.
PostgreSQL with pgvector is a mature, production-ready vector database:
-- Install pgvector
CREATE EXTENSION vector;
-- Store embeddings
CREATE TABLE documents (
 id SERIAL PRIMARY KEY,
 content TEXT,
 embedding vector(1536) -- OpenAI text-embedding-3-small dimensions
);
-- Create HNSW index for fast approximate nearest neighbor search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Semantic similarity search
SELECT 
 id,
 content,
 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;
-- Hybrid search: vector similarity + keyword filter
SELECT id, content
FROM documents
WHERE category = 'technical'
 AND ts_rank(to_tsvector(content), plainto_tsquery('kubernetes')) > 0.1
ORDER BY embedding <=> $1::vector
LIMIT 5;
pgvecto.rs (Rust-based alternative to pgvector) pushes performance further with better index compression and GPU-accelerated operations.
MySQL has no equivalent native vector search capability. You’d need to use a separate vector database (Pinecone, Weaviate, Qdrant) and manage the complexity of a polyglot persistence layer.
Verdict: PostgreSQL wins decisively if vector search matters to you.
Replication and High Availability
PostgreSQL
PostgreSQL’s streaming replication is battle-tested and flexible. Logical replication (introduced in PG 10, mature in PG 17) enables:
Partial replication (specific tables or rows)
Cross-version replication
Replication to non-PostgreSQL targets
-- Create publication on source
CREATE PUBLICATION my_pub FOR TABLE orders, products;
-- Create subscription on replica
CREATE SUBSCRIPTION my_sub
 CONNECTION 'host=primary-host dbname=mydb'
 PUBLICATION my_pub;
Tools like Patroni (automatic failover), pgBouncer (connection pooling), and Citus (horizontal sharding) are production-proven.
MySQL
MySQL’s GTID-based replication is reliable, and Group Replication (the foundation for InnoDB Cluster) provides multi-primary capabilities with automatic failover:
-- InnoDB Cluster setup (via MySQL Shell)
-- Provides automatic failover without external tools
dba.createCluster('myCluster')
cluster.addInstance('user@host2:3306')
cluster.addInstance('user@host3:3306')
MySQL’s replication story has historically been stronger for cloud managed services — AWS RDS Multi-AZ, Aurora MySQL, Google Cloud SQL for MySQL are all very mature.
Verdict: Roughly comparable, with MySQL having a slight edge in managed cloud environments due to more mature managed service offerings. PostgreSQL has caught up significantly with Amazon Aurora PostgreSQL and Google AlloyDB.
Ecosystem and Extensions
PostgreSQL’s extension ecosystem is one of its biggest advantages:
Extension
 What it does
 
pgvector
 Vector similarity search
 
PostGIS
 Geographic data (the gold standard)
 
TimescaleDB
 Time-series data
 
pg_cron
 In-database cron jobs
 
Citus
 Distributed PostgreSQL
 
pglogical
 Advanced logical replication
 
pg_partman
 Partition management
 
HypoPG
 Hypothetical indexes for planning
 
-- pg_cron: run scheduled tasks in SQL
SELECT cron.schedule(
 'cleanup-old-sessions',
 '0 3 * * *', -- 3 AM daily
 'DELETE FROM sessions WHERE expires_at < NOW() - INTERVAL ''7 days'''
);
-- PostGIS: geospatial queries
SELECT name, ST_Distance(location, ST_MakePoint(-73.9857, 40.7484))
FROM restaurants
WHERE ST_DWithin(location, ST_MakePoint(-73.9857, 40.7484), 0.01)
ORDER BY 2
LIMIT 10;
MySQL has fewer third-party extensions, but the community is active and the built-in features are comprehensive.
The Decision Framework
Photo by Marvin Meyer on Unsplash
Choose PostgreSQL when:
Complex queries and joins are common
You need vector search / AI features
Geospatial data is in scope
You value standards compliance (ANSI SQL, JSON/SQL standard)
You need flexible extensibility
Your team has PostgreSQL experience
Choose MySQL when:
You’re migrating from an existing MySQL codebase
Team expertise is already MySQL-oriented
You’re using a platform with tight MySQL integration (PlanetScale, Vitess)
Simple, high-throughput read workloads dominate
You need Group Replication’s built-in multi-primary support
Either works fine for:
Standard web application CRUD
Medium-scale transactional workloads
Cloud managed services (both have excellent managed offerings)
Summary
The 2026 answer is more nuanced than “just use Postgres”:
MySQL 9 is a genuinely good database that has closed many historical gaps. It’s not the MySQL 5.x of old. For teams with existing MySQL expertise or infrastructure, there’s no compelling reason to migrate.
PostgreSQL 17 remains the more capable system for complex workloads, and the ecosystem (pgvector, PostGIS, Citus) is unmatched. It’s the better default choice for new projects where the decision is open.
The AI feature gap is real. If you’re building anything with semantic search or vector similarity, PostgreSQL + pgvector is the pragmatic choice over managing a separate vector database.
The PostgreSQL community’s momentum is stronger — the pace of feature development, the growth of the extension ecosystem, and the quality of managed cloud options (Aurora PostgreSQL, AlloyDB, Neon, Supabase) make it the safer long-term bet.
But “safer bet” doesn’t mean MySQL is a bad choice. Pick the one your team can operate well.

PostgreSQL 17 vs MySQL 9: Which Database Should You Choose in 2026?

댓글