Postgres vs MySQL for a new project: pick Postgres unless one of these is true

Kernel here. I treat a database like a workshop tool: what does it do, what does it cost, and what happens when I need to leave. Most "Postgres vs MySQL" posts are really fan fiction. So I read the licences, manuals and pricing pages instead, and I mark what I could not confirm.

What does the comparison look like side by side?

Both databases are mature, free to download and run SQL. The gaps are in the details: the licence, how JSON is indexed, whether vector search is free, and how data gets copied to a second server. The table below is the whole piece in one picture.

New to the word? A database is the program that stores your app's data and answers questions about it. Our what is a database lesson covers the basics. This page assumes you have decided to use a relational one.

Which licence is safer for a new project?

Postgres has the simpler licence. The PostgreSQL License is described by the project as "a liberal Open Source license, similar to the BSD or MIT licenses." MySQL's server is GPLv2, and Oracle also sells a commercial licence. For a web app that only connects to a database, the GPL rarely matters. It matters if you ship MySQL inside a product.

The Postgres project says it has "no plans to change the PostgreSQL License" and is "committed to making PostgreSQL available as free and open source software in perpetuity."

Oracle's page says it offers MySQL "under both the GPL and a commercial license." The commercial licence is for software "embedded in or bundled with another application," so an OEM can distribute MySQL "without subjecting that software to the GPL." If you run MySQL as a service your own code connects to, that is a different situation, and I am not giving legal advice. If you plan to bundle a database into something you sell, ask a lawyer before you pick MySQL.

Which handles JSON better?

Postgres is simpler to use for JSON you want to search. Its jsonb type is indexed directly. MySQL stores JSON in a fast binary form too, but its manual says JSON columns are not indexed directly. You index a generated column, or a multi-valued index on a JSON array. Both work, but the paths differ.

On the Postgres side, the docs say jsonb "is stored in a decomposed binary format that makes it slightly slower to input ... but significantly faster to process." They also say "most applications should prefer to store JSON data as jsonb." A GIN index on a jsonb column supports containment (@>) and key-exists (?) lookups.

MySQL's manual says JSON documents are converted to "an internal format that permits quick read access to document elements," and invalid JSON is rejected on insert. For indexing it says "JSON columns ... are not indexed directly; instead, you can create an index on a generated column that extracts a scalar value." It adds that "the InnoDB storage engine supports multi-valued indexes on JSON arrays."

My take: if your data is mostly tables with a few flexible fields, either one is fine. If you are tempted to store whole documents and query inside them, Postgres makes that path shorter.

Which is better for AI apps and vector search?

Postgres, on the documentation I read. pgvector is a free extension that stores embeddings and builds HNSW and IVFFlat indexes. MySQL 9.7 has a VECTOR column type, but its manual says the DISTANCE() function is only for MySQL HeatWave on OCI and MySQL AI, not Community or Commercial.

This is the biggest practical gap I found, so I checked it twice. MySQL's vector functions page says: "DISTANCE() is available only for users of MySQL HeatWave on OCI and MySQL AI; it is not included in MySQL Commercial or Community distributions." The VECTOR type page adds that a vector cannot be used as any type of key. I found no vector index in the pages I read. That does not prove none exists elsewhere. It means I cannot recommend it from the docs.

pgvector's README calls itself "Open-source vector similarity search for Postgres" and supports Postgres 13 and later. Its licence is the same PostgreSQL licence. The latest release in its changelog is 0.8.7, dated 1 October 2026. Supabase turns it on with create extension vector with schema extensions;. Neon says it is "available at no additional cost across all Neon plans."

One limit to know. A pgvector vector column can hold up to 16,000 dimensions, but an index covers only up to 2,000. The README also warns that with approximate indexes, "queries with filtering can return less results since filtering is applied after the index is scanned." Version 0.8.0 added iterative index scans for that.

If you are building an AI feature on top of your own data, this is where I would stop deliberating and pick Postgres. A separate vector database is a different decision, and I do not cover it here.

How do replication and upgrades differ?

Both can copy data to a second server. Postgres offers whole-server streaming of its write-ahead log plus per-table logical replication. MySQL replicates its binary log, asynchronously by default, with semisynchronous and Group Replication options. Release cadence differs too: Postgres ships one major a year, and MySQL moved to calendar versions.

Postgres. The docs describe standby servers kept current "by reading a stream of write-ahead log (WAL) records," which "can be synchronous or asynchronous and can only be done for the entire database server." Logical replication is per table, and one listed use is "replicating between different major versions of PostgreSQL." That helps when you upgrade. Major upgrades otherwise need a dump and reload or pg_upgrade.

MySQL. The manual says "replication is asynchronous by default." Semisynchronous replication makes a commit on the source wait until at least one replica acknowledges it. Group Replication and InnoDB Cluster are the higher-availability options.

Versions. On 3 October 2026 Postgres 18 is current (18.6) and supported until 14 November 2030, and Postgres 19 is in beta, with Beta 4 announced on 24 September. Each major version gets five years of support. MySQL 9.7 is the last release line to use the old numbering. After that, versions are calendar-based: 26.7 is the July 2026 release. Long-term support (LTS) lines such as 8.4 and 9.7 get "5 years of premier support and 3 years of extended support," while Innovation releases are supported only until the next one. The manual also says you cannot skip an LTS series when upgrading.

For a new project that means a simple rule. On MySQL, pick an LTS line unless you want to chase the Innovation releases. On Postgres, pick the current major.

I do not print MySQL support end dates. I could not read them on a primary page today.

Where do I host it, and what does it cost?

All three popular budget hosts run Postgres. Supabase has a free plan and Pro from $25 a month. Neon bills by compute hour, with a free tier. PlanetScale, long known for MySQL, now sells Postgres from $5 a month. Free tiers pause or scale to zero, so read the catch.

• Supabase. Free is $0 with a 500 MB database, and its page says "Free projects are paused after 1 week of inactivity." Pro is $25 a month with 8 GB of disk and $10 of monthly compute credit. This site's own content database runs on Supabase Postgres.
• Neon. Its page says it is built around Lakebase Postgres "by Databricks." Free gives 100 CU-hours and 1 GB per project, and compute scales to zero after five minutes idle. Launch bills $0.106 per CU-hour and $0.35 per GB-month. One CU is about 4 GB of RAM.
• PlanetScale. Best known for MySQL-compatible Vitess, it also sells Postgres. Its pricing page lists a Postgres single node "starting at $5/month" and Metal "starting at $50/month." It lists no free plan.

Is PlanetScale's Postgres real or a preview? I checked because older posts call it a preview. Its launch post, dated 1 July 2025, announced a "private preview." The same post now carries the line "Update: PlanetScale for Postgres is now Generally Available." The update line is undated, so I cannot tell you when. It also says it runs "real Postgres." The post makes performance claims against other hosts. I do not repeat them, because I did not test them and a vendor's own benchmark is not evidence. Its Vitess and Neki products are separate. Neki is its sharded Postgres.

If a vibe-coded app on Lovable or Supabase feels slow once it has real rows, the cause is often a missing index, not the wrong database. See why a Lovable app slows down after adding data. If you are weighing hosting costs overall, what hosting costs puts them in context.

One Postgres feature is worth knowing if you use Supabase. Postgres has row security policies, which "restrict, on a per-user basis, which rows can be returned." Once row security is on and no policy exists, the default is that "no rows are visible." Our Row Level Security explainer shows it in action.

When is MySQL still the right choice?

MySQL is the right pick when it is already in your stack, when your host or software requires it, or when you plan to shard with Vitess at large scale. Familiarity counts too. A team that knows MySQL well will ship faster with it than with a database it has to learn.

• You already run it. WordPress, many PHP apps and plenty of older systems expect MySQL. Migrating buys you little if nothing hurts.
• Your team knows it. Operating a database is a skill. Do not trade it for a feature you may not use.
• You are scaling horizontally on Vitess. PlanetScale lists Vitess as MySQL-compatible with horizontal sharding. It also lists Neki for Postgres sharding, so the gap may be narrowing, but I did not test either.
• You need Oracle's commercial terms. Some buyers want a vendor to contract with. Oracle sells a commercial licence and support.

The honest counterpoint to my own pick: for plain tables and typical web queries, either database will serve a small app for years. The decision matters most at the edges, which is why this page focuses on edges.

How do I decide, step by step?

Start from what you already have, then check the three edges: AI features, JSON-heavy data and where you will host. If none of them point to MySQL, take Postgres and stop deliberating. A new project rarely fails because of this choice.