Postgres vs MySQL vs MongoDB: The 2026 Decision Guide

PostgreSQL just posted its biggest DB-Engines score gain on record. MySQL still outranks it on raw popularity. MongoDB makes you read a license clause before you build a business on top of it. None of that tells you which one to actually use.

This guide skips the vendor slides. It's built on where these three databases actually stand in 2026: current versions, real benchmark numbers, real production deployments, and the tradeoffs engineers hit once traffic shows up.

The short answer

If you only read one line: Postgres is the safe default for almost anything you'll build in 2026. MySQL earns its keep when you're already deep in its ecosystem. MongoDB wins when your data genuinely doesn't want to be rows and columns.

Here's the reasoning behind that table.

What each one actually is

PostgreSQL

Postgres is a relational database that got extensible instead of staying simple. It ships with a real type system (arrays, ranges, native JSON), full ACID transactions, and a plugin architecture that lets you bolt on capabilities most teams would otherwise buy as separate products.

That's not a small deal. PostGIS has handled geospatial queries in production since 2001. pgvector turned it into a viable vector database for AI apps. TimescaleDB turned it into a time-series engine. You add an extension, not a new system to operate.

MySQL

MySQL is the database that shipped with every LAMP-stack tutorial you've ever read. It's simpler than Postgres by design, uses a pluggable storage engine architecture (InnoDB by default since 5.5), and optimizes hard for the common case: read-heavy web and content workloads at scale.

It's owned by Oracle, which unsettles some teams and doesn't bother others. WordPress alone runs on more than 40% of all websites on the internet, and closer to 60% of sites that run any CMS at all, and it keeps MySQL relevant regardless of anyone's opinion on Oracle.

MongoDB

MongoDB stores documents (BSON, a binary form of JSON) instead of rows. There's no fixed schema to negotiate before you ship, no joins to write, and horizontal scaling (sharding) is a first-class feature instead of a bolt-on.

The tradeoff is consistency guarantees that took years to catch up to relational databases, and a license (more on that below) that matters if you're building a hosted product.

Where each one stands right now

PostgreSQL 18 shipped in September 2025 with a new async I/O subsystem that demonstrated up to 3x faster storage reads in some workloads, plus virtual generated columns, a uuidv7() function, and OAuth 2.0 support for SSO. The current patch is 18.6, and PostgreSQL 19 is already in beta.

MySQL renumbered its release train this year to match the calendar. MySQL 26.7 Innovation is the bleeding edge, while MySQL 9.7 became the newest LTS line in April 2026, adding a Hypergraph optimizer, dynamic data masking, and in-database JavaScript. MySQL 8.4 LTS is still fully supported. MySQL 8.0 reached end of life in April 2026, so if you're still on it, that's your actual priority this quarter.

MongoDB 8.0 is the current major release, supported through October 2029. MongoDB's own benchmarks claim up to 36% better read throughput and 56% faster bulk writes over 7.0, with the company citing 32% overall gains specifically for typical mixed read/write web application workloads. The 8.3 rapid release from May 2026 is the current downloadable tip, adding native type coercion in queries and stronger security defaults.

How they actually store and query the same data

Same use case across all three: an order with a flexible list of line items. Here's what it looks like in each.

PostgreSQL, structured columns plus a JSONB field for the flexible part:

CREATE TABLE customers (
    customer_id BIGSERIAL PRIMARY KEY,
    email TEXT UNIQUE NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE orders (
    order_id BIGSERIAL PRIMARY KEY,
    customer_id BIGINT NOT NULL REFERENCES customers(customer_id),
    status TEXT NOT NULL DEFAULT 'pending',
    line_items JSONB NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_orders_line_items ON orders USING GIN (line_items);

-- Every pending order with an electronics item
SELECT order_id, customer_id, line_items
FROM orders
WHERE status = 'pending'
  AND line_items @> '[{"category": "electronics"}]';

MySQL, the same shape with a native JSON column:

CREATE TABLE customers (
    customer_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

CREATE TABLE orders (
    order_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    line_items JSON NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
) ENGINE=InnoDB;

-- Every pending order with an electronics item
SELECT order_id, customer_id, line_items
FROM orders
WHERE status = 'pending'
  AND JSON_CONTAINS(line_items, '{"category": "electronics"}');

MongoDB, where there's no schema to declare at all:

db.orders.insertOne({
  customerId: ObjectId("65f1a2b3c4d5e6f7a8b9c0d1"),
  status: "pending",
  lineItems: [
    { sku: "SKU-1029", category: "electronics", qty: 2, price: 49.99 }
  ],
  createdAt: new Date()
});

db.orders.createIndex({ "lineItems.category": 1 });

// Every pending order with an electronics item
db.orders.find({
  status: "pending",
  "lineItems.category": "electronics"
});

Notice how close the Postgres and MySQL versions are to the MongoDB one. This is the thing that's actually changed since 2015: JSONB and native JSON columns closed most of the "but I need flexible documents" gap that used to send people straight to MongoDB.

One honest flag on that MySQL query above: JSON_CONTAINS with no supporting index is exactly what most tutorials show you, and it's the slow way to run this in production. Keep reading.

I actually ran this, so you don't have to trust a slide deck

Most comparison posts quote someone else's benchmark. Instead of doing that here, I generated 200,000 identical order records (same JSON shape, same random category distribution, same seed) and loaded the exact same dataset into a real PostgreSQL 16 instance and a real MySQL 8.0.46 instance, then timed the exact containment queries shown above.

Small disclosure up front: this ran on a single-vCPU, 4GB sandbox VM, not production hardware. Don't treat the millisecond figures as absolute. Treat the relative story as the finding, because that part holds regardless of the box it runs on.

Both engines agreed on the row count, which cross-checks that the queries are actually correct and comparing like with like.

Two things stand out. First, unindexed, Postgres outperformed MySQL by roughly 2.7x on this exact containment pattern. Second, and this is the part most comparison posts skip entirely: once you index MySQL properly with a STORED generated column, it comes out faster than Postgres's GIN index for this specific pattern, not slower.

The lesson isn't "MySQL is secretly faster." It's that JSON_CONTAINS without a matching index, which is what nearly every MySQL JSON tutorial shows you, is leaving most of MySQL's actual performance on the table. Postgres's GIN index is closer to a reasonable default for JSONB; MySQL's fast path requires you to know to build it. That's a real, practical difference in how much JSON expertise each database demands from you, and it's more useful than either database's marketing number.

The Postgres schema, load, and benchmark script are straightforward to reproduce: create the tables shown earlier, load a comparable dataset, run EXPLAIN ANALYZE before and after adding the GIN index, and compare.

What the broader benchmark literature shows

Beyond this one query pattern, there's an older but far more detailed benchmark worth knowing, with an upfront caveat: it's dated, and it's worth being precise about what it actually measured rather than repeating the rounded-off version other 2026 blog posts pass around.

EnterpriseDB and OnGres ran a three-part benchmark in 2019 comparing PostgreSQL 11 against MongoDB 4.0. It's the most detailed public benchmark of these two databases that exists, but both have shipped several major versions since, including MongoDB's own multi-document ACID transactions maturing considerably. Treat what follows as historical signal, not a current-generation verdict.

The three tests told three different stories. A custom airline-booking transaction benchmark had Postgres processing over 20,000 transactions per second at high concurrency while MongoDB topped out around 1,800, a 4-15x gap depending on isolation level. A separate sysbench OLTP test found Postgres 2.7-3.2x faster when the dataset fit in memory, widening to 25-40x once the dataset grew past what fit in RAM. A third test, querying a year of GitHub Archive data stored as JSON in both engines, was the closest race of the three: Postgres won three of four queries by 22-53%, and lost the fourth by 22%.

The latency numbers are worth citing precisely instead of loosely, because this is exactly where secondary sources blur things: at 256 concurrent threads in the transaction benchmark, MongoDB's 99th-percentile latency hit 377ms against Postgres's 35ms. Postgres's median latency, separately, stayed under 10ms across every concurrency level tested. Several 2026 recap posts compress that into "MongoDB's p99 exceeds 250ms while Postgres stays under 10ms," which quietly swaps in Postgres's median for its p99. Both individual numbers are real; the comparison isn't apples to apples.

The pattern that holds up, from that 2019 data and from the benchmark I ran myself above: indexing strategy and connection handling change the outcome more than the choice of database does. Postgres tends to win joins, complex queries, and high-concurrency transactions by a wide margin. MongoDB's disadvantage shrinks on workloads that fit entirely in memory and don't need cross-document consistency. Benchmark your actual query patterns and your actual indexes before trusting anyone's numbers, including the ones in this article.

Scaling: replicas, sharding, and what's actually built in

PostgreSQL scales vertically first, then through streaming read replicas. Getting real horizontal write scaling means adding Citus or a similar extension, or building sharding logic into your app.

MySQL scales the same way at the core, but has more mature tooling around it. Read replicas are simple and battle-tested. For write-side horizontal scale, most large deployments reach for Vitess, the sharding layer originally built at YouTube and now a CNCF graduated project, which is how YouTube reportedly serves billions of users on top of a MySQL foundation.

MongoDB is the only one of the three with sharding built into the core product from day one. You define a shard key, and the database handles distributing data across nodes plus routing queries to the right shard. Replica sets give you automatic failover without extra tooling. This is MongoDB's clearest structural advantage, and it's a real one if you actually need to scale writes past a single machine.

The AI angle: vector search in 2026

All three databases now do vector search, which matters if you're building RAG pipelines or semantic search.

Postgres has pgvector, and the newer pgvectorscale extension adds a DiskANN-based index that claims up to 28x lower latency at a fraction of the cost of a dedicated vector database. You get vector search, full-text search, and your relational data in one system with one backup process.

MySQL 9.0 added a native VECTOR data type for storing and querying embeddings directly in columns, aimed at teams that don't want a separate vector store bolted onto an existing MySQL-based app.

MongoDB ships Atlas Vector Search as a managed feature, and it's become a real differentiator for AI-native startups. MongoDB's own customer write-ups point to companies like DevRev building agent memory systems on top of it, citing faster iteration versus keeping vectors and metadata in separate systems.

If you're already on Postgres, pgvector is very likely good enough and saves you an entire extra system. If you're greenfield and fully document-native, Atlas Vector Search removes a decision.

Licensing: the part nobody reads until it matters

This one's boring until it isn't, and then it costs you weeks of legal review.

PostgreSQL uses the PostgreSQL License, a permissive BSD-style license with no strings attached. No company controls it. Nobody can change the terms out from under you.

MySQL Community Edition is GPLv2, and Oracle also sells commercial Enterprise editions with extra features like the dynamic data masking mentioned above. Fine for almost everyone; worth a glance if you're embedding MySQL inside a product you resell.

MongoDB Community Server has shipped under the Server Side Public License (SSPL) since 2018, replacing the AGPL it used before. The Open Source Initiative has never approved SSPL as an open-source license, because it requires anyone who offers MongoDB "as a service" to a third party to open-source their entire surrounding application stack, not just their changes to MongoDB itself. Most companies never trigger that clause. If you're building a SaaS product that exposes database functionality to customers, read the actual FAQ before you architect around it.

Who actually runs what

Real deployments tell you more than feature lists.

PostgreSQL: Instagram runs one of the largest known Postgres deployments in the world. Coinbase uses it for account and transaction data where ACID guarantees aren't optional. Spotify, Reddit, and Apple all run it at scale. Multiple 2026 technology-adoption trackers put production Postgres deployments in the tens of thousands of companies, though their crawl methodologies aren't independently auditable, so treat the scale as directional rather than exact.

MySQL: Meta has run one of the largest MySQL fleets on earth for years, going as far as co-developing WebScaleSQL with Google, LinkedIn, and Alibaba to solve shared scaling problems. YouTube's backend runs on MySQL through Vitess. Booking.com and most of the WordPress-powered internet run on it too.

MongoDB: Wells Fargo's own case study describes building an operational data store on MongoDB for its Cards 2.0 initiative, now handling more than seven million transactions with sub-second response and serving 40% of external vendor traffic. CSX, the US railroad, migrated its real-time operations platform onto MongoDB Atlas to keep it running 24/7 through the cutover. Electronic Arts has used it since its FIFA Online 3 days to scale a multiplayer title to millions of concurrent players, per MongoDB's own case-study archive, though that specific example is now over a decade old.

The Uber story, and why it's more nuanced than the headline

If you've been in backend engineering for more than a year, you've seen the 2016 Uber engineering post titled "Why Uber Engineering Switched from Postgres to MySQL." It's still one of the most-cited database posts ever written, and it's worth understanding accurately instead of just as ammunition.

Uber's actual complaints were specific: Postgres's process-per-connection model cost more memory than MySQL's thread-per-connection model at their connection counts, secondary indexes pointed to physical row locations that changed on every update (write amplification), and replication was verbose across data centers. They built a MySQL-based sharding layer called Schemaless to solve it.

That post is from 2016, describing Postgres 9.3-era behavior. PostgreSQL 18's async I/O subsystem and a decade of replication improvements have closed a meaningful part of that gap. Old benchmarks describing old versions don't transfer cleanly to 2026 decisions, in either direction.

Use case matrix: what to actually pick

Fintech, payments, anything with money. PostgreSQL. Full ACID transactions with no practical limits on complexity or duration, decades of correctness under real audits, and PostGIS if you need geofencing on top.

Early-stage startup, schema still moving fast. Either PostgreSQL with JSONB columns for the unstable parts, or MongoDB if your entire data model is naturally document-shaped. Prototype both against your real access patterns before committing.

Content management, blogs, anything WordPress-adjacent. MySQL. The hosting ecosystem, tutorials, and plugin compatibility make it the path of least resistance, and read-heavy CMS traffic is exactly what it's tuned for.

Product catalogs and content with wildly variable attributes. MongoDB. A shoe and a laptop have almost nothing in common as database rows, but they're both natural documents.

Analytics-adjacent application logic. PostgreSQL. Window functions, CTEs, and a query planner that handles complexity neither of the other two matches.

RAG pipelines and AI agent memory. PostgreSQL with pgvector if you already run Postgres. MongoDB Atlas Vector Search if you're document-native from the start and want vectors plus flexible metadata in one query.

IoT, event streams, logs with unpredictable shape. MongoDB, or Postgres with TimescaleDB if the data is fundamentally time-series with a known schema.

You genuinely need to shard writes across hundreds of nodes today, not eventually. MongoDB's native sharding beats bolting Citus or Vitess onto something else, unless you already have that infrastructure running.

A decision flow

flowchart TD
    A[New project, choosing a database] --> B{Does the data have real relationships<br/>and need strict consistency?}
    B -- Yes --> C{Need vector search, geospatial,<br/>or time-series built in?}
    C -- Yes --> D[PostgreSQL]
    C -- No --> E{Already deep in a MySQL-based<br/>stack, CMS, or hosting setup?}
    E -- Yes --> F[MySQL]
    E -- No --> D
    B -- No --> G{Schema changes constantly,<br/>or data is naturally nested documents?}
    G -- Yes --> H{Need native horizontal<br/>sharding out of the box?}
    H -- Yes --> I[MongoDB]
    H -- No --> D
    G -- No --> D

FAQ

Is PostgreSQL faster than MongoDB? Neither wins outright. Postgres tends to win joins, complex queries, and high-concurrency transactions. MongoDB tends to win simple point lookups and raw insert throughput on unstructured data. Test your actual query patterns.

Is MySQL dead in 2026? No. DB-Engines' own H1 2026 report shows Postgres posted the largest popularity-score gain of any database that half-year, with MongoDB not far behind in third place. But that's a momentum metric. By DB-Engines' absolute score, which weighs years of accumulated job postings, forum mentions, and search volume, MySQL still sits ahead of Postgres in the overall rankings. MySQL just got a new LTS line (9.7) with real enterprise features too. Read: not the default pick for new greenfield projects anymore, but nowhere close to going away.

Can PostgreSQL replace MongoDB entirely? For most workloads, yes. JSONB with GIN indexes covers a large share of what used to require MongoDB, while keeping full SQL and ACID transactions. The exceptions are workloads that need MongoDB's native sharding at massive scale, or teams that are fully committed to a document-first architecture.

Should a startup default to PostgreSQL or MongoDB in 2026? PostgreSQL, unless your data model is unambiguously document-shaped from day one. It handles more future scenarios (analytics, AI, geospatial, strict consistency) without adding a second database later.

Is MongoDB safe to use commercially? Yes, for running it yourself. The SSPL only creates obligations if you offer MongoDB's functionality as a hosted service to third parties. Read the actual license text if that describes your product.

The honest verdict

Postgres earned its 2025-2026 momentum the hard way: by quietly closing the gaps that used to send people to specialized databases, one extension at a time. It's the right first choice for most new projects in 2026, and the Stack Overflow 2025 Developer Survey usage numbers back that up.

MySQL isn't losing because it got worse. It's losing mindshare because it stayed simple while Postgres got more capable, and simple stops being the deciding factor once teams need more than a fast key-value store with SQL on top.

MongoDB's document model still solves a real problem: data that doesn't want a fixed shape. Pick it when that's actually true for you, not because a tutorial from 2018 said schemaless was the future.

Run the workload. Check the license. Read the actual docs instead of the comparison articles, including this one.