Postgres vs MySQL 2026: default database for new projects

PostgreSQL is the default database for new projects in 2026. The surveys agree, the managed cloud ecosystem favors it, and the pgvector extension alone tips the scale for any team building AI features. MySQL is not dead — it still wins specific workloads — but “just use MySQL” is no longer the neutral safe choice it was in 2015.

Who this is for

Developers starting a new backend in 2026 who haven’t decided on a database yet. If you’re already running MySQL in production and not hitting a wall, this is not a case for migration. The cost of switching a live system almost never pays off unless you have a concrete, measurable problem.

Versions in scope

PostgreSQL 17 (released September 26, 2024; actively supported)
MySQL 8.4 LTS (released April 30, 2024; supported through approximately April 2032)

Benchmark figures are cited per source. Survey data is from Stack Overflow 2025 (~65,000 respondents) and JetBrains Developer Ecosystem Survey 2025 (~24,534 respondents, April–June 2025). Managed cloud pricing is current as of May 2026.

Where the industry landed

PostgreSQL overtook MySQL by every signal that matters for new project decisions.

Stack Overflow 2025: PostgreSQL at 55.6% vs MySQL 40.5% (all developers). Among professional developers only: 58.2% vs 39.6%. Source: survey.stackoverflow.co/2025.

JetBrains 2025: PostgreSQL at 66% vs MySQL 50% across 24,534 developers. Source: devecosystem-2025.jetbrains.com.

The learner exception: MySQL still leads among learners (47.7% vs PostgreSQL 39.2%). MySQL’s dominance in PHP/WordPress tutorials and shared hosting means it’s often the first database people touch. That’s a lagging indicator — it tells you what’s taught, not what gets built.

The trend is not a blip. PostgreSQL’s ascent has been consistent across multiple surveys for three years running. The main driver: cloud-native teams default to Supabase (PostgreSQL), Neon (PostgreSQL), or Railway (PostgreSQL) for the managed layer. The managed MySQL options have gotten more expensive.

What’s new in each

PostgreSQL 17

PostgreSQL 17 shipped September 26, 2024, with three improvements that matter operationally:

20× less memory for VACUUM — autovacuum, which prevents table bloat, now uses a fraction of the working memory it previously needed. This makes PostgreSQL usable on small instances without tuning autovacuum away.
2× write throughput under high concurrency — relevant to any write-heavy workload (analytics ingest, event sourcing, audit logs).
2× COPY export performance — useful for bulk ETL pipelines and data warehouse loads.

Source: postgresql.org/about/news/postgresql-17-released-2936.

MySQL 8.4 LTS

MySQL 8.4 LTS shipped April 30, 2024. It is the first LTS release in the MySQL 8.x line, with support through approximately April 2032. Key changes:

mysql_native_password is disabled by default. Client libraries that haven’t switched to caching_sha2_password will break. Check your driver versions before upgrading.
Direct upgrade from MySQL 5.7 to 8.4 is not supported. You must go through MySQL 8.0 as an intermediate step. If you’re still on 5.7, plan two upgrade hops, not one.

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

The LTS designation is a win for teams that need predictable maintenance windows. It is not a feature leap.

Head-to-head: three areas that decide most projects

JSON storage

PostgreSQL’s JSONB type stores JSON as binary, not text. It supports GIN indexes on any path inside the document. A query on a nested field in a 10-million-row JSONB column can use the index and return in milliseconds without scanning every row.

MySQL’s JSON type stores documents as text with some index support via generated columns. To query a nested field efficiently, you create a virtual generated column for that path, then index the generated column manually. It works. It’s more setup, and it doesn’t extend cleanly when the document structure changes.

If your schema involves semi-structured data — user-configurable metadata, event payloads, config blobs — PostgreSQL’s JSONB is the clear choice. MySQL’s approach is adequate for a handful of specific paths; it breaks down for general-purpose document querying.

Full-text search

PostgreSQL’s tsvector and tsquery system supports stemming, custom dictionaries, phrase search, and ranking out of the box. You can tune stop words, add language-specific dictionaries, and rank results by recency-weighted relevance without an external system.

MySQL’s FULLTEXT indexes handle basic English keyword search adequately. Phrase queries work. Multi-language stemming does not. Custom dictionaries require plugin configuration.

Neither replaces a dedicated search engine (Elasticsearch, Typesense, Meilisearch) for complex product search. For internal search, admin dashboards, or moderate-traffic site search where adding another service is not worth it, PostgreSQL’s full-text implementation is stronger.

Replication and HA

MySQL’s InnoDB Cluster (Group Replication + MySQL Router) provides automatic failover with a relatively turnkey setup compared to what PostgreSQL required historically. If you’re self-hosting and need HA without operational complexity, MySQL has had a slight edge here.

PostgreSQL’s WAL streaming replication is reliable and battle-tested at scale. Tools like Patroni, Stolon, and CloudNativePG handle automated failover for self-hosted PostgreSQL. These work well but require more configuration than InnoDB Cluster out of the box.

In 2026, this distinction matters primarily for self-hosted deployments. If you’re using a managed service (Supabase, Neon, RDS, Cloud SQL), replication and failover are handled for you regardless of which database you pick. The managed cloud layer erases this advantage for the majority of new projects.

PostgreSQL-only features

Two extensions define the PostgreSQL advantage for 2026 workloads:

pgvector: Stores and queries high-dimensional embedding vectors natively. Enables semantic search, similarity ranking, and RAG (retrieval-augmented generation) pipelines without a separate vector database. Every AI-adjacent project in 2026 that needs embeddings reaches for pgvector. MySQL has no equivalent.

PostGIS: Geospatial indexing, distance queries, and geometry operations at database level. If your application has any geographic data — store locations, delivery routing, map overlays — PostGIS is the mature standard. MySQL has spatial support but it is significantly less capable for complex geospatial operations.

If your project involves AI features or location data, PostgreSQL is not optional.

Managed cloud in 2026

The managed database market has shifted toward PostgreSQL in the past two years.

Supabase (PostgreSQL): Free tier includes 500 MB database, auth, storage, and realtime listeners. Pro at $25/month adds more compute and removes the paused-project policy. The bundled auth and storage make it a compelling full-stack backend for small to medium projects. Pricing: supabase.com/pricing.

Neon (PostgreSQL): Free tier includes 0.5 GB, scale-to-zero (database pauses when idle), and 10 database branches for preview environments. Pay-as-you-go at $0.106/compute-unit-hour. The branching model maps cleanly to pull request preview environments. Pricing: neon.com/pricing.

PlanetScale (MySQL): Removed its free tier in 2024. Paid plans start at $39/month. Still a strong choice for teams that need Vitess-level horizontal sharding and have the budget for it.

Aurora MySQL vs Aurora PostgreSQL: For AWS shops, Aurora MySQL is generally cheaper for pure OLTP workloads. Aurora PostgreSQL tends to pull ahead on analytical and mixed queries. If you’re on AWS and cost-optimizing a read-heavy OLTP system, compare current pricing directly at aws.amazon.com/rds/aurora/pricing/. For analytical or mixed workloads, Aurora PostgreSQL is the stronger default.

For most teams starting fresh without a cloud preference, Supabase and Neon make PostgreSQL the path of least resistance.

Performance

A peer-reviewed MDPI benchmark compared PostgreSQL and MySQL on SELECT queries across 1M rows (MDPI, 2024):

Primary SELECT queries:

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

Complex queries under simultaneous insert load:

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

The benchmark caveat applies here: synthetic benchmarks measure isolated operations. In production, query planner decisions, index design, connection pooling, and network latency dominate over engine-level differences. Don’t pick a database on benchmark numbers for a p99 latency target you haven’t measured.

When MySQL still wins

Honest cases where MySQL is the right answer:

WordPress and PHP CMSes: WordPress is MySQL-native. Every WordPress plugin assumes MySQL. If you’re running WordPress, the question is not which database to pick — the question is which MySQL to use.

Existing MySQL team: Operational knowledge matters. If your team has deep MySQL expertise, well-tuned queries, and reliable runbooks for your MySQL version, switching to PostgreSQL means relearning tools, rewriting some queries, and retraining on different behavior for things like NULL handling, string collation, and transaction isolation defaults. The switch is possible; the cost is real.

Simple read-heavy OLTP on a budget on AWS: If your application does primarily single-row indexed reads on AWS, Aurora MySQL’s lower price point for pure OLTP workloads may justify the choice for a cost-sensitive project. Compare current Aurora pricing before committing.

Vitess-scale sharding: PlanetScale’s Vitess foundation is purpose-built for horizontal MySQL sharding at large scale. If you’re heading toward Twitter-level write volume, that ecosystem is worth evaluating.

Decision matrix

Use case	Recommended
New SaaS / web app	PostgreSQL
WordPress / PHP CMSes	MySQL
JSON-heavy or schema-flexible data	PostgreSQL
AI features / embeddings (pgvector)	PostgreSQL
Geospatial data (PostGIS)	PostgreSQL
Advanced full-text search	PostgreSQL
Serverless / CI/CD preview environments	Neon (PostgreSQL)
Full-stack backend bundle (auth + storage + DB)	Supabase (PostgreSQL)
AWS OLTP cost optimization	Aurora MySQL
Vitess-scale horizontal sharding	PlanetScale (MySQL)
Existing MySQL team, no active pain	MySQL

Verdict

Default to PostgreSQL for new projects unless you have a specific reason in the matrix above that points to MySQL.

The managed cloud ecosystem (Supabase, Neon, RDS PostgreSQL, Cloud SQL for PostgreSQL) makes PostgreSQL as easy to operate as MySQL was in the LAMP stack era. pgvector removes the need for a separate vector store for AI features. JSONB removes the need for MongoDB for semi-structured data. The developer survey numbers reflect a real shift in where teams are building.

MySQL remains a solid, production-proven database. It is not going away, and running it in 2026 is not a mistake. But “I’m not sure which to pick” no longer defaults to MySQL — it defaults to PostgreSQL.

For teams evaluating their full backend stack alongside the database choice, see our Django vs FastAPI 2026 comparison for how the Python framework layer pairs with either database, and our Go vs Rust 2026 comparison for teams building in compiled languages.

Caveats

Benchmark figures from the MDPI paper (doi.org/10.3390/fi16100382) reflect specific hardware and query patterns. Your workload will produce different numbers. Treat the directional signal (PostgreSQL wins on both primary and complex queries in this benchmark) as the takeaway, not the millisecond values.

Survey figures are from self-selected respondents. The Stack Overflow 2025 developer survey skews toward web developers; the JetBrains survey skews toward JetBrains tool users. Neither is a random sample of all developers worldwide.

There are no affiliate links in this article. Supabase and Neon are mentioned by direct URL. The /go/supabase and /go/neon affiliate slugs do not yet exist in the toolchew affiliate table.