Postgres vs. MySQL for a new product in 2026

You’re starting a new product and need a relational database. The two open source defaults are PostgreSQL (“Postgres”) and MySQL. Both are mature, fast enough for nearly any early-stage product, and available as a managed service from every major cloud. This guide is for founders and engineers who want to make the call once, on current facts, and move on. The short version: for most new products in 2026, Postgres is the safer default, but MySQL is still a fine choice when your team or your hosting plan points that way.

The short answer

Choose Postgres if you want the broadest set of features in the open source edition, especially vector search through pgvector, rich JSON indexing, and built-in full-text search.

Choose Postgres if you want the widest choice of managed hosts, including developer-focused ones like Neon and Supabase.

Choose MySQL if your team already runs it well, or you expect to need horizontal sharding through Vitess (for example on PlanetScale).

Choose MySQL if you lean heavily on very fast, low-drama schema changes on big tables and like InnoDB’s instant column operations.

Either is fine if you’re building a standard CRUD app with a few dozen tables. Pick the one your team knows and spend your energy elsewhere.

Where each one stands today

Postgres. The current major version is PostgreSQL 18, released on September 25, 2025. The latest minor release is 18.6 (August 13, 2026). PostgreSQL 19 is in beta (Beta 4 shipped on September 24, 2026) and is not yet generally available. The project ships one major version a year and supports each one for five years, so 18 is supported until November 2030. PostgreSQL 14 stops getting fixes on November 12, 2026, so if you see it on a hosting menu, skip it.

PostgreSQL 18 brought a new asynchronous I/O subsystem, a built-in uuidv7() function for time-ordered IDs, virtual generated columns, OAuth 2.0 authentication, and faster major-version upgrades, because planner statistics now carry over during pg_upgrade.

MySQL. MySQL now runs on two tracks. Long-term support (LTS) releases get only bug and security fixes, with five years of premier support and three years of extended support under Oracle’s policy. Innovation releases add features quickly and are supported only until the next Innovation release. The current LTS lines are 8.4 (released April 2024) and 9.7 (released April 21, 2026; the download page lists 9.7.2 as current). The Innovation track has moved to calendar-style numbers: MySQL 26.7.0 shipped on July 28, 2026. MySQL 8.0 reached community end of life on April 30, 2026.

MySQL 9.7 moved several things that used to be Enterprise-only into the free Community edition: the hypergraph query optimizer, several Group Replication components, telemetry, and full insert, update, and delete support for JSON Duality Views.

For a new product, the practical choices are PostgreSQL 18 or MySQL 8.4 / 9.7 LTS. Don’t start a new product on an Innovation release unless you’re happy to upgrade every few months.

What actually matters

These six criteria decide the choice for most new products.

1. Licensing and governance

Postgres uses the PostgreSQL License, a permissive license similar to BSD or MIT. It’s developed by the PostgreSQL Global Development Group, a community project that no single company controls, and the project has committed to keeping it free and open source.

MySQL is owned by Oracle. The Community edition is licensed under GPLv2, and Oracle sells a commercial license for companies that want to ship MySQL inside software they distribute without GPL obligations. If you only run MySQL as a server behind your web app, that distinction rarely comes up. It matters if you plan to ship an appliance or an on-premises product that bundles the database. Some features stay in the paid Enterprise edition (9.7’s new dynamic data masking is one), and some observers, as InfoQ reported this year, have raised concerns about MySQL’s shrinking contributor base.

2. JSON

Both store JSON in a binary format, so reads don’t reparse text. The difference is indexing. Postgres’s jsonb type supports GIN indexes (a GIN index is an inverted index, the kind that maps each key or value back to the rows containing it) across a whole document, so containment queries like “find every event where payload contains this key and value” can use an index without you planning ahead. MySQL doesn’t index JSON columns directly. You index a generated column that pulls out one value, or use multi-valued indexes on JSON arrays. That works well when you know which fields you’ll query; it’s more work when you don’t.

3. Vector search and extensions

If your product will store embeddings for AI features, this is the biggest gap. pgvector is an open source Postgres extension that adds vector types plus HNSW and IVFFlat indexes (both are approximate nearest-neighbor indexes) with L2, inner product, cosine, and other distance functions. It supports Postgres 13 and newer and comes preinstalled at many hosts.

MySQL has a VECTOR data type, but its documentation states that the DISTANCE() function “is available only for users of MySQL HeatWave on OCI and MySQL AI; it is not included in MySQL Commercial or Community distributions.” In plain MySQL you can store vectors but not search them by similarity in the database.

4. Full-text search

Both have it built in. Postgres has tsvector and tsquery types with stemming (matching “rats” to “rat”), stop words, phrase search, ranking, and GIN indexes, plus configurations for many languages. MySQL supports FULLTEXT indexes on InnoDB tables, with natural-language, boolean, and query-expansion modes. Either is enough for searching a help center or a product catalog.

5. Online schema changes

This is MySQL’s best argument. In MySQL 8.4, adding, dropping, and renaming a column uses ALGORITHM=INSTANT by default, which changes only metadata, and adding a secondary index runs in place while reads and writes continue.

Postgres has improved here too. Adding a column with a constant default stores the default in metadata, so it’s fast even on large tables. CREATE INDEX CONCURRENTLY builds an index without blocking writes, at the cost of a slower build. But many ALTER TABLE forms take an ACCESS EXCLUSIVE lock by default, which blocks everything on that table while it runs. You can manage this with short lock timeouts, but you have to know to do it.

6. Replication and high availability

Postgres supports physical streaming replication (byte-for-byte copies, good for read replicas and failover) and logical replication, a publish-and-subscribe model that copies changes table by table. Automatic failover usually comes from your managed service or separate tooling.

MySQL ships Group Replication with single-primary or multi-primary modes and automatic primary election. Oracle recommends wrapping it in InnoDB Cluster with MySQL Router so your app’s connections follow the primary. If you self-host and want built-in failover, MySQL gives you more in the box.

Operations, briefly

Two Postgres habits to know. First, Postgres keeps old row versions after updates and deletes (that’s how its multiversion concurrency control works), and VACUUM reclaims the space. Autovacuum is on by default and handles this for most apps, but write-heavy tables sometimes need tuning. Second, Postgres starts a new server process for each connection, so serverless apps that open many short connections need a connection pooler in front. Check whether your host provides one.

Comparison table

Criterion	PostgreSQL 18	MySQL 8.4 / 9.7 LTS
Current status	18.6 current; 19 in beta	9.7 LTS (April 2026); 8.4 LTS; Innovation track at 26.7
Support window	5 years per major	5 years premier + 3 extended per LTS
License	PostgreSQL License (permissive)	GPLv2 Community; commercial license from Oracle
Governance	Community (PostgreSQL Global Development Group)	Oracle
JSON indexing	GIN indexes on whole `jsonb` documents	Generated-column and multi-valued indexes
Vector search	pgvector (HNSW, IVFFlat), open source	`VECTOR` type; `DISTANCE()` only on HeatWave/MySQL AI
Full-text search	Built in, stemming and ranking	Built in, `FULLTEXT` on InnoDB
Schema changes	Fast add-column; concurrent index builds; many `ALTER`s lock the table	Instant add/drop/rename column by default; in-place index builds
Built-in HA	Streaming and logical replication; failover via tooling or host	Group Replication, InnoDB Cluster
Sharding path	Newer options such as PlanetScale’s Neki	Vitess (PlanetScale)

Managed options, as of October 2026

Most new products should use a managed database. Here’s where each engine stands on the main hosts. Prices are as of October 2026.

Amazon RDS. RDS for PostgreSQL supports versions 11 through 18, with 18.6 the latest and PostgreSQL 19 Beta 4 in RDS’s Preview environment. RDS for MySQL runs 8.4 under standard support until July 31, 2029. MySQL 8.0 now runs only under paid RDS Extended Support. MySQL 9.7 and 26.7 are available only in the RDS Database Preview environment, which is not for production and deletes instances after 60 days. If you want MySQL 9.7 LTS on RDS in production today, you can’t have it yet.
Amazon Aurora. AWS’s managed database built on its own distributed storage, with MySQL- and PostgreSQL-compatible editions. AWS also offers Aurora DSQL, a distributed, PostgreSQL-compatible serverless database.
Google Cloud SQL. Supports MySQL 9.7 and 8.4 (8.4 is the default for new instances) and PostgreSQL up to 18, which is the default.
Azure Database for PostgreSQL. Supports 11 through 18 (18.6 current). On 18 you can’t use the new io_uring async I/O setting, and some extensions aren’t yet supported.
Azure Database for MySQL. 8.0 and 8.4 are generally available; Azure’s standard support for 8.0 ends January 31, 2027. Innovation releases (9.5 at last update) are preview only, and servers are deleted after 30 days.
Neon. Serverless Postgres, now part of Databricks. Compute scales to zero when idle, and you can create database branches for previews and tests. The free plan includes 100 compute-unit hours and 1 GB of storage per project. The Launch plan bills $0.106 per CU-hour and $0.35 per GB-month of storage.
Supabase. Postgres bundled with auth, file storage, and an API layer. The free plan includes a 500 MB database and up to two active projects, but free projects pause after a week of inactivity. Pro starts at $25 a month with 8 GB of disk per project.
PlanetScale. Offers both engines. Postgres starts at $5 a month for a single node and $15 a month for a three-node high-availability cluster. Vitess-based MySQL starts at $39 a month. Its Vitess workflow uses branches and deploy requests with non-blocking schema changes. PlanetScale also offers Neki, a sharded Postgres built from scratch rather than forked from Vitess.

The pattern: AWS, Google Cloud, and Azure all run PostgreSQL 18 in production, while MySQL 9.7 LTS is production-ready only on Cloud SQL among the three.

Which one for you

Solo founder or small team. Postgres on Neon or Supabase gets you a free or cheap start, branching for previews, and pgvector for the AI feature you’ll probably add. Watch Supabase’s free-tier pausing and Neon’s scale-to-zero wake-up if you need instant first responses.

Growing startup on AWS or Google Cloud. Postgres on RDS, Aurora, or Cloud SQL is the low-risk path. If your team is a MySQL shop, MySQL 8.4 LTS on RDS or 9.7 on Cloud SQL is perfectly good. Just note that 8.4 is the newest LTS RDS runs in production right now.

Product expecting very large write volume. If you’re confident you’ll need sharding, Vitess-backed MySQL has the longer track record; PlanetScale notes it underpins MySQL sharding at companies like Slack and GitHub. Postgres sharding options such as Neki are newer. Most products never reach this point, so don’t pick a database for scale you may not need.

Regulated company. Both are offered as managed services by AWS, Google Cloud, and Azure; check each provider’s compliance programs against your requirements. Decide based on your cloud’s support for the version you want and on your team’s experience. Write the decision down in a technical decision record so auditors and future hires can see why.

Shipping an on-premises or embedded product. Read the licenses closely. Postgres’s permissive license is simpler to bundle. MySQL’s GPLv2 may push you toward Oracle’s commercial license.

Mistakes to avoid

Starting on an end-of-life version. PostgreSQL 14 loses support in November 2026; MySQL 8.0 already has. Start on PostgreSQL 18 or MySQL 8.4/9.7.
Treating an Innovation or beta release as production-ready. MySQL Innovation releases and PostgreSQL 19 betas are for testing.
Running ALTER TABLE on a busy Postgres table without a plan. Set a lock timeout, use CREATE INDEX CONCURRENTLY, and test on a copy first.
Opening a database connection per request from serverless code. Use a pooler, especially with Postgres.
Assuming MySQL’s VECTOR type gives you similarity search. In Community MySQL it doesn’t.

On lock-in and migration: both engines speak SQL, but moving between them isn’t trivial. Data types, JSON functions, full-text syntax, and stored procedures differ. Extensions like pgvector and host features like Supabase Auth or PlanetScale deploy requests add more surface to migrate. Keep your SQL portable where it’s cheap to do so, and think of a switch as a project, not a weekend. If you’re weighing a managed service against running your own, our build vs. buy guide walks through the tradeoffs.

A quick checklist

Pick a supported LTS or current major: PostgreSQL 18, or MySQL 8.4 or 9.7.
Confirm your chosen host runs that version in production, not just in preview.
List the features you need in year one: JSON queries, vector search, full-text search, sharding.
If you need vector search, choose Postgres with pgvector, or plan a separate vector store.
Plan how you’ll ship schema changes without downtime.
Put a connection pooler in front of Postgres if your app runs on serverless functions.
Check the license if you’ll distribute the database with your software.
Record the decision and the reasons in a technical decision record.