Postgres vs MySQL 2026: database mặc định cho dự án mới

PostgreSQL là database mặc định cho dự án mới trong năm 2026. Các cuộc khảo sát đều đồng thuận, hệ sinh thái managed cloud nghiêng về phía PostgreSQL, và riêng extension pgvector đã đủ sức làm nghiêng cán cân cho bất kỳ team nào đang xây dựng tính năng AI. MySQL không chết — nó vẫn thắng ở một số workload cụ thể — nhưng “cứ dùng MySQL” không còn là lựa chọn an toàn mặc định như năm 2015 nữa.

Bài viết này dành cho ai

Các lập trình viên đang bắt đầu backend mới trong năm 2026 và chưa quyết định database. Nếu bạn đang vận hành MySQL trong production và không gặp vấn đề gì, đây không phải lập luận để migration. Chi phí chuyển đổi một hệ thống đang chạy gần như không bao giờ bù đắp được lợi ích trừ khi bạn có vấn đề cụ thể, có thể đo lường được.

Phiên bản đang xét

PostgreSQL 17 (phát hành ngày 26 tháng 9 năm 2024; đang được hỗ trợ tích cực)
MySQL 8.4 LTS (phát hành ngày 30 tháng 4 năm 2024; được hỗ trợ đến khoảng tháng 4 năm 2032)

Các số liệu benchmark được trích dẫn theo nguồn. Dữ liệu khảo sát từ Stack Overflow 2025 (~65.000 người tham gia) và JetBrains Developer Ecosystem Survey 2025 (~24.534 người tham gia, tháng 4–6 năm 2025). Giá managed cloud tính đến tháng 5 năm 2026.

Xu hướng của ngành

PostgreSQL đã vượt MySQL trên mọi tín hiệu đáng quan tâm cho quyết định dự án mới.

Stack Overflow 2025: PostgreSQL ở mức 55.6% so với MySQL 40.5% (tính tất cả developer). Riêng với professional developer: 58.2% so với 39.6%. Nguồn: survey.stackoverflow.co/2025.

JetBrains 2025: PostgreSQL ở mức 66% so với MySQL 50% trên 24.534 developer. Nguồn: devecosystem-2025.jetbrains.com.

Ngoại lệ với người mới học: MySQL vẫn dẫn đầu trong nhóm học viên (47.7% so với PostgreSQL 39.2%). MySQL chiếm ưu thế trong các tutorial PHP/WordPress và shared hosting khiến nó thường là database đầu tiên mọi người tiếp xúc. Đây là chỉ số trễ — nó cho bạn biết cái gì được dạy, không phải cái gì được xây dựng.

Xu hướng này không phải ngẫu nhiên nhất thời. PostgreSQL đã tăng trưởng đều đặn qua nhiều cuộc khảo sát trong ba năm liên tiếp. Nguyên nhân chính: các team cloud-native mặc định chọn Supabase (PostgreSQL), Neon (PostgreSQL), hoặc Railway (PostgreSQL) cho tầng managed. Các tùy chọn managed MySQL ngày càng đắt hơn.

Điểm mới trong mỗi phiên bản

PostgreSQL 17

PostgreSQL 17 ra mắt ngày 26 tháng 9 năm 2024, với ba cải tiến đáng chú ý trong vận hành:

Giảm 20× bộ nhớ cho VACUUM — autovacuum, ngăn table bloat, giờ dùng một phần nhỏ working memory so với trước. Điều này giúp PostgreSQL dùng được trên các instance nhỏ mà không cần điều chỉnh cấu hình autovacuum.
Tăng 2× write throughput khi concurrency cao — phù hợp với bất kỳ workload ghi nặng nào (analytics ingest, event sourcing, audit log).
Tăng 2× hiệu suất COPY export — hữu ích cho ETL pipeline hàng loạt và data warehouse load.

Nguồn: postgresql.org/about/news/postgresql-17-released-2936.

MySQL 8.4 LTS

MySQL 8.4 LTS ra mắt ngày 30 tháng 4 năm 2024. Đây là bản LTS đầu tiên trong dòng MySQL 8.x, được hỗ trợ đến khoảng tháng 4 năm 2032. Những thay đổi quan trọng:

mysql_native_password bị tắt theo mặc định. Các client library chưa chuyển sang caching_sha2_password sẽ bị lỗi. Kiểm tra phiên bản driver trước khi nâng cấp.
Nâng cấp trực tiếp từ MySQL 5.7 lên 8.4 không được hỗ trợ. Bạn phải đi qua MySQL 8.0 như một bước trung gian. Nếu bạn vẫn đang dùng 5.7, hãy lên kế hoạch nâng cấp hai bước, không phải một.

Nguồn: dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-0.html.

Nhãn LTS là tin tốt cho các team cần maintenance window có thể dự đoán. Đây không phải bước nhảy vọt về tính năng.

So sánh trực tiếp: ba yếu tố quyết định hầu hết dự án

JSON storage

Kiểu JSONB của PostgreSQL lưu JSON ở dạng nhị phân, không phải văn bản. Nó hỗ trợ GIN index trên bất kỳ path nào trong document. Một query trên trường lồng nhau trong cột JSONB 10 triệu dòng có thể dùng index và trả kết quả trong mili giây mà không cần quét toàn bộ bảng.

Kiểu JSON của MySQL lưu document dạng văn bản với một số hỗ trợ index qua generated column. Để query trường lồng nhau hiệu quả, bạn phải tạo virtual generated column cho path đó, rồi index thủ công generated column đó. Cách này hoạt động được, nhưng cần thêm bước setup và không mở rộng tốt khi cấu trúc document thay đổi.

Nếu schema của bạn có dữ liệu bán cấu trúc — metadata do user cấu hình, event payload, config blob — JSONB của PostgreSQL là lựa chọn rõ ràng. Cách tiếp cận của MySQL đủ dùng cho một vài path cụ thể; nó kém hiệu quả khi query document mục đích chung.

Full-text search

Hệ thống tsvector và tsquery của PostgreSQL hỗ trợ stemming, custom dictionary, phrase search, và ranking ngay từ đầu. Bạn có thể tinh chỉnh stop word, thêm dictionary theo ngôn ngữ cụ thể, và xếp hạng kết quả theo độ liên quan có trọng số thời gian mà không cần hệ thống bên ngoài.

FULLTEXT index của MySQL xử lý tốt tìm kiếm keyword tiếng Anh cơ bản. Phrase query hoạt động. Stemming đa ngôn ngữ thì không. Custom dictionary cần cấu hình plugin.

Cả hai đều không thay thế được search engine chuyên dụng (Elasticsearch, Typesense, Meilisearch) cho product search phức tạp. Với internal search, admin dashboard, hoặc site search traffic vừa phải mà không đáng thêm một service riêng, full-text của PostgreSQL mạnh hơn.

Replication và HA

InnoDB Cluster của MySQL (Group Replication + MySQL Router) cung cấp automatic failover với setup tương đối đơn giản so với những gì PostgreSQL yêu cầu trước đây. Nếu bạn self-host và cần HA mà không muốn vận hành phức tạp, MySQL có lợi thế nhỏ ở điểm này.

WAL streaming replication của PostgreSQL đáng tin cậy và đã được kiểm chứng trong production ở quy mô lớn. Các tool như Patroni, Stolon, và CloudNativePG xử lý automated failover cho PostgreSQL self-hosted. Chúng hoạt động tốt nhưng cần cấu hình nhiều hơn InnoDB Cluster.

Năm 2026, sự khác biệt này chủ yếu quan trọng với deployment self-hosted. Nếu bạn dùng managed service (Supabase, Neon, RDS, Cloud SQL), replication và failover đều được xử lý sẵn dù bạn chọn database nào. Tầng managed cloud xóa bỏ lợi thế này cho phần lớn dự án mới.

Tính năng chỉ có ở PostgreSQL

Hai extension định nghĩa lợi thế của PostgreSQL cho workload năm 2026:

pgvector: Lưu và query embedding vector nhiều chiều ngay trong database. Cho phép semantic search, similarity ranking, và pipeline RAG (retrieval-augmented generation) mà không cần vector database riêng. Mọi dự án liên quan đến AI năm 2026 cần embedding đều dùng pgvector. MySQL không có tương đương.

PostGIS: Geospatial indexing, distance query, và thao tác geometry ở tầng database. Nếu ứng dụng của bạn có bất kỳ dữ liệu địa lý nào — vị trí cửa hàng, routing giao hàng, map overlay — PostGIS là chuẩn mực đã được kiểm chứng. MySQL có spatial support nhưng kém khả năng hơn đáng kể với các thao tác geospatial phức tạp.

Nếu dự án của bạn liên quan đến tính năng AI hoặc dữ liệu địa lý, PostgreSQL không phải lựa chọn tùy ý.

Managed cloud năm 2026

Thị trường managed database đã dịch chuyển về phía PostgreSQL trong hai năm qua.

Supabase (PostgreSQL): Gói miễn phí gồm database 500 MB, auth, storage, và realtime listener. Pro ở $25/tháng thêm compute và bỏ chính sách tạm dừng dự án. Auth và storage đi kèm giúp nó trở thành full-stack backend hấp dẫn cho dự án vừa và nhỏ. Pricing: supabase.com/pricing.

Neon (PostgreSQL): Gói miễn phí gồm 0.5 GB, scale-to-zero (database tạm dừng khi không hoạt động), và 10 database branch cho preview environment. Pay-as-you-go ở $0.106/compute-unit-hour. Model phân nhánh phù hợp với pull request preview environment. Pricing: neon.com/pricing.

PlanetScale (MySQL): Đã bỏ gói miễn phí từ năm 2024. Gói trả phí bắt đầu từ $39/tháng. Vẫn là lựa chọn mạnh cho team cần horizontal sharding ở mức Vitess và có ngân sách cho nó.

Aurora MySQL vs Aurora PostgreSQL: Với team trên AWS, Aurora MySQL thường rẻ hơn cho pure OLTP workload. Aurora PostgreSQL có ưu thế hơn với analytical và mixed query. Nếu bạn đang dùng AWS và tối ưu chi phí cho hệ thống OLTP read-heavy, hãy so sánh pricing trực tiếp tại aws.amazon.com/rds/aurora/pricing/. Với analytical hoặc mixed workload, Aurora PostgreSQL là lựa chọn mặc định tốt hơn.

Với hầu hết team bắt đầu mới mà không có ưu tiên cloud cụ thể, Supabase và Neon đưa PostgreSQL trở thành con đường ít trở ngại nhất.

Hiệu suất

Một benchmark được peer-review trên MDPI so sánh PostgreSQL và MySQL trên SELECT query qua 1 triệu dòng (MDPI, 2024):

Primary SELECT query:

PostgreSQL: 0.6–0.8 ms
MySQL: 9–12 ms

Complex query dưới đồng thời insert:

PostgreSQL: 0.7–0.9 ms
MySQL: 7–13 ms

Benchmark chỉ đo thao tác riêng lẻ trong môi trường tổng hợp. Trong production, quyết định của query planner, thiết kế index, connection pooling, và network latency mới là những thứ chi phối hơn sự khác biệt ở tầng engine. Đừng chọn database dựa trên con số benchmark cho p99 latency target mà bạn chưa đo lường thực tế.

Khi nào MySQL vẫn thắng

Những trường hợp thực tế mà MySQL là câu trả lời đúng:

WordPress và PHP CMS: WordPress là native với MySQL. Mọi WordPress plugin đều giả định MySQL. Nếu bạn đang chạy WordPress, câu hỏi không phải là chọn database nào — mà là chọn MySQL nào.

Team đang dùng MySQL: Kiến thức vận hành có giá trị. Nếu team của bạn có chuyên môn MySQL sâu, query được tối ưu tốt, và runbook đáng tin cậy cho phiên bản đang dùng, thì chuyển sang PostgreSQL đồng nghĩa với học lại công cụ, viết lại một số query, và học lại hành vi khác nhau của các thứ như NULL handling, string collation, và transaction isolation default. Chuyển đổi được; chi phí có thực.

OLTP đơn giản, read-heavy, ngân sách hạn chế trên AWS: Nếu ứng dụng của bạn chủ yếu đọc single-row indexed trên AWS, mức giá thấp hơn của Aurora MySQL cho pure OLTP workload có thể biện minh cho lựa chọn này với dự án nhạy cảm về chi phí. Hãy so sánh Aurora pricing hiện tại trước khi quyết định.

Sharding Vitess-scale: Nền tảng Vitess của PlanetScale được xây dựng chuyên biệt cho horizontal MySQL sharding ở quy mô lớn. Nếu bạn đang tiến tới write volume ở mức Twitter, hệ sinh thái đó đáng được đánh giá.

Ma trận quyết định

Use case	Khuyến nghị
SaaS / web app mới	PostgreSQL
WordPress / PHP CMS	MySQL
Dữ liệu JSON-heavy hoặc schema linh hoạt	PostgreSQL
Tính năng AI / embedding (pgvector)	PostgreSQL
Dữ liệu địa lý (PostGIS)	PostgreSQL
Full-text search nâng cao	PostgreSQL
Serverless / CI/CD preview environment	Neon (PostgreSQL)
Full-stack backend bundle (auth + storage + DB)	Supabase (PostgreSQL)
Tối ưu chi phí OLTP trên AWS	Aurora MySQL
Horizontal sharding Vitess-scale	PlanetScale (MySQL)
Team đang dùng MySQL, không có vấn đề gì	MySQL

Kết luận

Mặc định dùng PostgreSQL cho dự án mới trừ khi bạn có lý do cụ thể trong ma trận trên chỉ sang MySQL.

Hệ sinh thái managed cloud (Supabase, Neon, RDS PostgreSQL, Cloud SQL for PostgreSQL) giúp PostgreSQL dễ vận hành như MySQL ở thời kỳ LAMP stack. pgvector loại bỏ nhu cầu vector store riêng cho tính năng AI. JSONB loại bỏ nhu cầu MongoDB cho dữ liệu bán cấu trúc. Các con số khảo sát developer phản ánh sự dịch chuyển thực sự trong nơi các team đang xây dựng.

MySQL vẫn là database solid, đã được kiểm chứng trong production. Nó không biến mất, và dùng nó trong năm 2026 không phải sai lầm. Nhưng “tôi không biết nên chọn cái nào” không còn mặc định là MySQL nữa — nó mặc định là PostgreSQL.

Với team đang đánh giá toàn bộ backend stack cùng với lựa chọn database, xem so sánh Django vs FastAPI 2026 của chúng tôi về cách tầng Python framework kết hợp với cả hai database, và so sánh Go vs Rust 2026 cho team xây dựng với ngôn ngữ biên dịch.

Lưu ý

Số liệu benchmark từ bài MDPI (doi.org/10.3390/fi16100382) phản ánh phần cứng và query pattern cụ thể. Workload của bạn sẽ cho ra con số khác. Hãy lấy tín hiệu định hướng (PostgreSQL thắng trên cả primary và complex query trong benchmark này) làm takeaway, không phải các giá trị mili giây cụ thể.

Số liệu khảo sát từ người tham gia tự chọn. Stack Overflow Developer Survey 2025 nghiêng về web developer; JetBrains survey nghiêng về người dùng công cụ JetBrains. Không cái nào là mẫu ngẫu nhiên của tất cả developer trên thế giới.

Bài viết này không có affiliate link. Supabase và Neon được đề cập bằng URL trực tiếp.