PostgreSQL vs MySQL vs MongoDB: The Definitive Database Comparison

PostgreSQL vs MySQL vs MongoDB: The Definitive Comparison for 2026

In 2026, these three databases power approximately 80% of all new applications. PostgreSQL dominates the DB-Engines trending charts. MySQL still runs behind a staggering fraction of the web. MongoDB owns the document database category outright. If you are building something new this year, your database shortlist almost certainly has at least two of these on it.

But here is the thing: choosing between them should take about five minutes for most projects. The decision is rarely as agonizing as the hundreds of comparison articles make it seem. What you need is a clear framework, honest tradeoffs, and enough concrete detail to feel confident you made the right call.

This article gives you that framework, then spends the rest of its length explaining the reasoning behind it.

The Five-Minute Decision Flowchart

Before diving into architecture and benchmarks, here is the quick path:

1. Do you need truly schemaless documents with native horizontal sharding across hundreds of nodes? Your data has no predictable shape, you are ingesting millions of varied documents per second, and you need automatic geographic distribution. Choose MongoDB.

2. Are you building on WordPress, Magento, or a legacy PHP stack that assumes MySQL? The ecosystem integration is deep, migration would cost more than any database advantage could recoup, and your queries are simple CRUD. Choose MySQL.

3. Everything else? You want relational integrity but also need JSONB documents, vector search, geospatial queries, time-series, full-text search, or any combination. You want the most powerful query language available. You care about data correctness and extensibility. Choose PostgreSQL.

That is the honest recommendation. The rest of this article explains why, with enough technical depth that you can defend your choice in an architecture review.

Architecture Overview

Understanding why each database behaves differently starts with how they store data and manage concurrency.

PostgreSQL: Processes, Heap Tables, and MVCC

PostgreSQL forks a dedicated OS process for each client connection. Each process has isolated memory, which provides strong fault containment -- a misbehaving query cannot corrupt another session. The tradeoff is that connection overhead is higher, making connection pooling (PgBouncer, Supavisor) effectively mandatory above a few hundred connections.

Data lives in heap tables with no inherent row ordering. Indexes -- B-tree, GIN, GiST, SP-GiST, BRIN, and the hash type -- are separate structures that point into the heap. This separation means PostgreSQL supports an extraordinary variety of index types optimized for different access patterns.

MVCC is implemented by storing multiple physical row versions directly in the table. An UPDATE creates a new tuple and marks the old one as dead. Readers never block writers. The cost is that dead tuples accumulate until VACUUM reclaims them, making autovacuum tuning a core operational concern.

MySQL/InnoDB: Threads, Clustered Indexes, and Undo Logs

MySQL uses a thread-per-connection model within a single process. Threads share memory space, which scales to thousands of connections without an external pooler. This lighter overhead is a genuine advantage for connection-heavy OLTP workloads.

InnoDB organizes data in a clustered index -- the primary key B-tree IS the table. Row data is stored at the leaf nodes of the primary key index. This means primary key lookups are a single B-tree traversal, which is marginally faster than PostgreSQL's heap-then-index dance.

MVCC uses an undo log. The current row version stays in the clustered index, and undo records in a rollback segment reconstruct older versions for transactions that need them. This avoids PostgreSQL-style table bloat but adds overhead when long-running transactions must traverse many undo records.

MongoDB: Documents, BSON, and WiredTiger

MongoDB stores data as BSON (Binary JSON) documents in collections. There is no fixed schema -- each document in a collection can have a completely different shape. The WiredTiger storage engine (default since 3.2) uses document-level locking with snapshot isolation for reads.

WiredTiger organizes data in a B-tree with internal page compression. Documents are stored contiguously, so reading a single document is a single I/O operation that returns the complete object -- no joins, no secondary lookups. Write operations use a write-ahead log (journal) and checkpoint-based durability.

The architectural difference is fundamental: MongoDB optimizes for accessing self-contained documents. PostgreSQL and MySQL optimize for assembling data from normalized tables via joins.

Data Modeling: Relational vs Document vs Hybrid

This is where your choice has the most long-term impact. Let me model the same business scenario -- an e-commerce order system -- in all three.

PostgreSQL (Normalized Relational)

CREATE TABLE customers (
    customer_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_name TEXT NOT NULL,
    customer_email TEXT NOT NULL UNIQUE,
    membership_tier TEXT NOT NULL DEFAULT 'standard'
);

CREATE TABLE orders (
    order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT NOT NULL REFERENCES customers(customer_id),
    total_amount NUMERIC(12, 2) NOT NULL,
    order_status TEXT NOT NULL DEFAULT 'pending',
    created_at_utc TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE order_items (
    order_item_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    order_id BIGINT NOT NULL REFERENCES orders(order_id),
    product_sku TEXT NOT NULL,
    product_name TEXT NOT NULL,
    quantity INT NOT NULL,
    unit_price NUMERIC(10, 2) NOT NULL
);

Three tables, foreign keys enforced, no data duplication. Updating a customer email happens in one place. The tradeoff: reading a complete order requires a JOIN.

PostgreSQL (Hybrid with JSONB)

CREATE TABLE orders_hybrid (
    order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT NOT NULL REFERENCES customers(customer_id),
    items JSONB NOT NULL,
    total_amount NUMERIC(12, 2) NOT NULL,
    order_status TEXT NOT NULL DEFAULT 'pending',
    created_at_utc TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- GIN index for querying inside the JSONB
CREATE INDEX idx_orders_hybrid_items ON orders_hybrid USING GIN (items);

This is PostgreSQL doing both. The customer relationship is relational (data integrity), but items are embedded as JSONB (read performance). You get the best of both worlds -- at the cost of some denormalization in the items array.

MySQL (Relational)

CREATE TABLE customers (
    customer_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    customer_name VARCHAR(255) NOT NULL,
    customer_email VARCHAR(255) NOT NULL UNIQUE,
    membership_tier VARCHAR(50) NOT NULL DEFAULT 'standard'
) ENGINE=InnoDB;

CREATE TABLE orders (
    order_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL,
    order_status VARCHAR(50) NOT NULL DEFAULT 'pending',
    created_at_utc TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
) ENGINE=InnoDB;

CREATE TABLE order_items (
    order_item_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_sku VARCHAR(100) NOT NULL,
    product_name VARCHAR(255) NOT NULL,
    quantity INT NOT NULL,
    unit_price DECIMAL(10, 2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(order_id)
) ENGINE=InnoDB;

Structurally similar to PostgreSQL. MySQL 8+ added a JSON column type, but its JSON support is significantly less capable -- no GIN indexing, limited query operators, and JSON functions are verbose compared to PostgreSQL's -> and ->> operators.

MongoDB (Document)

db.orders.insertOne({
  customer: {
    name: "Alice Chen",
    email: "[e-mail]",
    tier: "premium"
  },
  items: [
    { sku: "SKU-1234", name: "Widget", quantity: 3, unit_price: 29.99 },
    { sku: "SKU-5678", name: "Gadget", quantity: 1, unit_price: 149.99 }
  ],
  total_amount: 239.96,
  status: "shipped",
  created_at: ISODate("2026-02-15T10:30:00Z")
})

Everything in one document. Reads are fast -- one query returns the complete order. But the customer data is embedded. If Alice changes her email, you must update it in every order document. This is the fundamental tension of document databases: read optimization at the cost of write complexity and data consistency.

The Modeling Verdict

MongoDB's model is simpler for reads but dangerous for data that changes. PostgreSQL gives you both options -- normalize what needs integrity, embed what needs performance. MySQL handles the relational model competently but lacks PostgreSQL's JSONB hybrid capability.

Query Capabilities

The query language differences are where PostgreSQL separates itself from both competitors.

Finding High-Value Customers

PostgreSQL:

WITH customer_totals AS (
    SELECT c.customer_id,
           c.customer_name,
           SUM(o.total_amount) AS lifetime_spend,
           COUNT(o.order_id) AS order_count,
           ROW_NUMBER() OVER (ORDER BY SUM(o.total_amount) DESC) AS spend_rank
    FROM customers c
    JOIN orders o ON c.customer_id = o.customer_id
    WHERE o.created_at_utc >= now() - INTERVAL '1 year'
    GROUP BY c.customer_id, c.customer_name
)
SELECT customer_name, lifetime_spend, order_count, spend_rank
FROM customer_totals
WHERE spend_rank <= 100;

CTEs, window functions, interval arithmetic -- all in one readable query.

MySQL:

SELECT c.customer_name,
       SUM(o.total_amount) AS lifetime_spend,
       COUNT(o.order_id) AS order_count
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.created_at_utc >= DATE_SUB(NOW(), INTERVAL 1 YEAR)
GROUP BY c.customer_id, c.customer_name
ORDER BY lifetime_spend DESC
LIMIT 100;

MySQL 8+ added CTEs and window functions, so this query is achievable. But in practice MySQL's optimizer makes less sophisticated decisions about execution plans for complex CTEs, and window functions with complex frame clauses can perform significantly worse than on PostgreSQL.

MongoDB:

db.orders.aggregate([
  { $match: { created_at: { $gte: new Date("2025-02-15") } } },
  { $group: {
      _id: "$customer.email",
      customer_name: { $first: "$customer.name" },
      lifetime_spend: { $sum: "$total_amount" },
      order_count: { $sum: 1 }
  }},
  { $sort: { lifetime_spend: -1 } },
  { $limit: 100 },
  { $setWindowFields: {
      sortBy: { lifetime_spend: -1 },
      output: { spend_rank: { $rank: {} } }
  }}
])

MongoDB's aggregation pipeline is powerful but verbose. $setWindowFields (added in 5.0) brought window function equivalents, but the pipeline syntax is harder to read and reason about than SQL for analytical queries. Cross-collection operations (the equivalent of JOINs) require $lookup, which is limited to equality matches and does not benefit from the decades of join optimization that SQL databases have.

Query Language Verdict

PostgreSQL has the most complete SQL implementation of any open-source database. MySQL is competent for standard queries but falls behind on complex analytics. MongoDB's aggregation pipeline is capable but verbose, and cross-document operations are a fundamental weakness.

Performance by Workload

No single database wins every workload. Here is an honest assessment.

Workload	Winner	Why
Simple CRUD (primary key lookups)	MySQL	Clustered index means PK lookup = one B-tree traversal to the row. Thread model handles high connection counts efficiently.
Complex analytics (joins, CTEs, window functions)	PostgreSQL	Superior query planner, parallel query execution, hash joins, merge joins. Handles multi-table analytical queries that bring MySQL to its knees.
Document reads (fetch entire object)	MongoDB	Single I/O retrieves the complete document. No join assembly. Lowest latency for read-heavy document workloads.
Vector similarity search	PostgreSQL	pgvector provides IVFFlat and HNSW indexes. MongoDB Atlas Vector Search exists but is cloud-only. MySQL has no native vector support.
Geospatial queries	PostgreSQL (PostGIS) or MongoDB	PostGIS is the gold standard for complex spatial analysis. MongoDB has solid built-in geospatial support that is simpler to set up.
Time-series data	PostgreSQL (TimescaleDB)	TimescaleDB adds automatic partitioning, continuous aggregates, and compression. MongoDB time-series collections are newer and less mature. MySQL has no time-series extension.
Full-text search	PostgreSQL or MongoDB	Both have strong built-in full-text search. PostgreSQL's tsvector/GIN approach is more configurable. MongoDB's Atlas Search (Lucene-based) is arguably easier.
High-concurrency simple writes	MySQL or MongoDB	MySQL's thread pool and MongoDB's document-level locking both handle massive write throughput efficiently. PostgreSQL's process model adds overhead here.
Mixed OLTP + analytics	PostgreSQL	The only one that handles both well without a separate system. MySQL struggles with analytics. MongoDB struggles with cross-document analytics.

The pattern is clear: MySQL wins at simple operations, MongoDB wins at document-shaped reads, and PostgreSQL wins at everything involving complexity, flexibility, or specialized workloads via extensions.

Scaling Strategies

This is the section where MongoDB advocates lean in hard, so let me be fair and precise.

MongoDB: Native Horizontal Sharding

MongoDB was designed for horizontal scaling from the start. Its sharding distributes data across multiple nodes based on a shard key. For truly massive datasets (tens of terabytes and beyond) with predictable access patterns, this works well.

The reality check: most applications never need horizontal sharding. A single PostgreSQL or MySQL server with 64 cores, 256 GB RAM, and NVMe storage handles tens of billions of rows comfortably. Sharding adds operational complexity -- shard key selection is irreversible, cross-shard queries are expensive, and rebalancing is disruptive.

MySQL: Vitess, ProxySQL, and Read Replicas

MySQL scaling is a mature ecosystem. Read replicas handle read scaling. Vitess (used by Slack, GitHub, and YouTube) provides horizontal sharding with a proxy layer. ProxySQL handles connection pooling and query routing.

The tradeoff: these are external systems that add operational layers. MySQL itself does not shard natively.

PostgreSQL: Partitioning, Citus, and Read Replicas

PostgreSQL scales vertically extremely well -- single-node PostgreSQL handles workloads that would require a MongoDB cluster. For read scaling, streaming replication with read replicas is mature and reliable.

For horizontal sharding, Citus (now part of the core Azure PostgreSQL offering and available as an open-source extension) provides distributed PostgreSQL. Declarative partitioning handles time-series and range-based data efficiently without external tools.

Scaling Verdict

MongoDB's built-in sharding is a genuine advantage if you actually need it. Most applications do not. PostgreSQL and MySQL scale vertically to a degree that surprises teams coming from the "horizontal scale everything" mindset. When you do need to scale out, all three have viable paths -- they just differ in how much is built-in versus bolted-on.

Extensions and Ecosystem

This is where PostgreSQL's advantage becomes unfair.

PostgreSQL: The Extension Ecosystem

PostgreSQL's extension system is arguably its most important feature. Extensions can add new data types, index types, storage engines, query languages, and entire subsystems. The major ones:

• PostGIS -- The gold standard for geospatial data. Used by government agencies, logistics companies, and mapping platforms worldwide.
• TimescaleDB -- Time-series database built as an extension. Automatic partitioning, continuous aggregates, columnar compression.
• pgvector -- Vector similarity search for AI/ML embeddings. HNSW and IVFFlat indexes.
• pg_stat_statements -- Query performance statistics. The foundation of PostgreSQL observability.
• pg_cron -- Cron-based job scheduling inside the database.
• pg_partman -- Advanced partition management.
• Citus -- Distributed PostgreSQL (horizontal sharding).
• pgcrypto -- Cryptographic functions.
• pg_trgm -- Trigram-based fuzzy text matching.
• hstore, ltree, cube, earthdistance -- Specialized data types for specific domains.

There are hundreds more. This extension ecosystem means PostgreSQL can be a document database, a time-series database, a vector database, a geospatial database, and a relational database -- simultaneously, in one deployment, with one operational footprint.

MySQL: Limited Plugin System

MySQL has a plugin architecture for storage engines (InnoDB, MyRocks), authentication, and auditing. But it cannot add new data types, new index types, or new query capabilities through plugins. You get what MySQL ships with, plus whatever your managed provider adds.

MySQL's strength is ecosystem adjacency: the sheer number of ORMs, frameworks, hosting providers, and tutorials that support it.

MongoDB: No Extension System

MongoDB has no extension mechanism. Features come from MongoDB Inc. via new releases, or from their Atlas cloud platform (which adds search, vector search, analytics, etc. as managed services). If you need a capability MongoDB does not have, you add another system to your architecture.

Ecosystem Verdict

PostgreSQL's extensions mean you often deploy one database instead of three. A stack that might require MongoDB (documents) + Elasticsearch (search) + a time-series database + a relational database can often be consolidated into PostgreSQL with the right extensions. This has enormous implications for operational cost and complexity.

Cost of Ownership

Licensing

All three are free to use. PostgreSQL has the most permissive license (PostgreSQL License, similar to MIT). MongoDB uses the Server Side Public License (SSPL), which restricts offering MongoDB as a service. MySQL is dual-licensed -- GPLv2 for community, commercial license for embedding.

Operational Complexity

PostgreSQL requires understanding autovacuum, connection pooling, and WAL management. The learning curve is real but the operational surface is well-documented.

MySQL is arguably the simplest to operate for basic workloads. The defaults are reasonable, replication setup is well-documented, and the thread model means you may not need connection pooling.

MongoDB requires understanding sharding concepts, replica set elections, and the implications of schemaless design (schema validation, data consistency patterns). The operational model for a sharded cluster is significantly more complex than a single PostgreSQL server.

Hosting Options

All three are available on every major cloud provider. PostgreSQL has the widest range of managed options: Amazon RDS/Aurora, Google Cloud SQL/AlloyDB, Azure Database, Supabase, Neon, Tembo, Crunchy Bridge, and dozens more. MySQL has RDS/Aurora, Cloud SQL, PlanetScale, and Vitess-based providers. MongoDB has Atlas (their own cloud) and limited third-party options due to SSPL licensing.

Talent Pool

All three have large talent pools, but the mix differs. MySQL developers are abundant in the PHP/WordPress/web development space. PostgreSQL developers are more common in data-intensive, enterprise, and startup environments. MongoDB developers cluster in JavaScript/Node.js ecosystems.

Monitoring and Observability

PostgreSQL provides the deepest observability APIs of the three through pg_stat_statements, pg_stat_activity, pg_stat_user_tables, pg_stat_bgwriter, and its extensive catalog system. Every aspect of database behavior -- query performance, lock contention, vacuum progress, replication lag, buffer cache hit ratios -- is exposed through queryable views.

Tools like myDBA.dev leverage this transparency to provide 75+ automated health checks, EXPLAIN plan analysis, index recommendations, and extension-specific monitoring for PostGIS, pgvector, TimescaleDB, and pg_cron. The depth of PostgreSQL's self-reporting means third-party monitoring tools can provide insights that are simply not possible with MySQL or MongoDB's more limited statistics interfaces.

MySQL exposes performance_schema and information_schema, which are useful but less granular. performance_schema has higher overhead than PostgreSQL's pg_stat_statements and is sometimes disabled in production for performance reasons.

MongoDB provides db.serverStatus(), db.currentOp(), and profiling. The profiler must be explicitly enabled and has noticeable overhead. Atlas (MongoDB's cloud platform) provides solid monitoring, but self-hosted MongoDB monitoring requires more effort.

When to Choose Each Database

Choose MongoDB When:

• Your data is genuinely document-shaped with deeply nested, variable structures that would be painful to normalize
• You need native horizontal sharding across dozens or hundreds of nodes for truly massive scale-out
• Your access patterns are dominated by reading and writing complete documents by ID
• Your team has deep MongoDB expertise and your use case is document-centric
• You are building an event store, content management system, or IoT ingestion pipeline where documents are append-mostly

Choose MySQL When:

• You are building on WordPress, Drupal, Magento, or other platforms that assume MySQL
• Your workload is dominated by simple CRUD operations with high connection counts
• You need the simplest possible operational model for a relational database
• Your team's expertise is MySQL-centric and your queries are straightforward
• You are running a read-heavy web application where MySQL's replication and caching ecosystem shines

Choose PostgreSQL When:

• You need relational integrity AND flexible document storage (JSONB)
• Your queries involve complex joins, CTEs, window functions, or analytical workloads
• You need specialized capabilities: geospatial (PostGIS), vector search (pgvector), time-series (TimescaleDB)
• Data correctness is non-negotiable and you want the strongest constraint enforcement
• You want one database that handles multiple workload types instead of deploying separate systems
• You are building a SaaS application, fintech system, analytics platform, or anything where query power and extensibility matter
• You want the broadest choice of managed hosting providers without vendor lock-in

The Comprehensive Comparison Table

Feature	PostgreSQL	MySQL	MongoDB
License	PostgreSQL (MIT-like)	GPLv2 / Commercial	SSPL
Data model	Relational + JSONB hybrid	Relational + limited JSON	Document (BSON)
Schema enforcement	Strict with optional JSONB flexibility	Strict (with strict mode)	Optional (schema validation available)
ACID transactions	Full, all operations	Full (InnoDB)	Multi-document since 4.0
Query language	SQL (most complete open-source implementation)	SQL (standard, some gaps)	MQL (MongoDB Query Language)
JOINs	All types, highly optimized	All types, less optimized for complex cases	$lookup (limited, no index optimization)
CTEs (WITH queries)	Full support, recursive, materialized hints	Basic support since 8.0	Not available
Window functions	Full support, all frame types	Basic support since 8.0	$setWindowFields since 5.0
Subquery optimization	Excellent (flattening, decorrelation)	Improved in 8.0, still lags	Limited
Parallel query	Yes (scans, joins, aggregates, sorts)	Limited (single-query parallelism in 8.0.14+)	Yes (within sharded clusters)
Full-text search	Built-in (tsvector/GIN), configurable	Built-in (basic), limited customization	Atlas Search (Lucene-based), strong
JSON support	JSONB with GIN indexing, rich operators	JSON column type, verbose functions	Native (documents are JSON/BSON)
Geospatial	PostGIS (industry gold standard)	Basic spatial functions	Built-in, solid for common use cases
Vector search	pgvector (HNSW, IVFFlat)	None	Atlas Vector Search (cloud only)
Time-series	TimescaleDB extension	None	Time-series collections (basic)
Partitioning	Declarative (range, list, hash)	Range, list, hash, key	Sharding (range, hash, zone)
Replication	Streaming (sync/async), logical	Async, semi-sync, group replication	Replica sets (automatic failover)
Horizontal sharding	Citus extension, Foreign Data Wrappers	Vitess, ProxySQL (external)	Native (built-in)
Connection model	Process per connection (needs pooling at scale)	Thread per connection (scales higher natively)	Thread pool
Extension system	Rich (PostGIS, pgvector, TimescaleDB, 300+)	Limited plugin system	None
Index types	B-tree, GIN, GiST, SP-GiST, BRIN, Hash	B-tree, Full-text, Spatial, Hash	B-tree, Compound, Text, Geospatial, Hashed
Partial indexes	Yes	No	Yes (sparse indexes)
Expression indexes	Yes	Yes (functional indexes since 8.0.13)	No
Covering indexes (INCLUDE)	Yes	No	Yes (covered queries via compound indexes)
Row-level security	Built-in (RLS policies)	No	Field-level redaction (Atlas only)
Stored procedures	PL/pgSQL, PL/Python, PL/V8, etc.	SQL, limited PL	Server-side JavaScript (deprecated focus)
Change data capture	Logical replication / logical decoding	Binary log parsing (Debezium)	Change streams
Managed hosting options	RDS, Aurora, Cloud SQL, AlloyDB, Supabase, Neon, Crunchy, Tembo, many more	RDS, Aurora, Cloud SQL, PlanetScale	Atlas (primary), limited third-party due to SSPL
Default operational complexity	Medium (vacuum, pooling)	Low (good defaults)	Medium-High (replica sets, sharding)
Talent pool focus	Enterprise, SaaS, data-intensive	Web/PHP, WordPress ecosystem	Node.js, JavaScript ecosystem
DB-Engines rank (2026)	#1 trending	#2 overall	#1 document

The Honest Bottom Line

If you are reading this article trying to make a decision, here is the most direct advice I can give:

PostgreSQL is the default choice for new projects in 2026. Not because it is trendy, but because it genuinely handles the widest range of workloads in a single system. JSONB gives you document flexibility when you need it. Extensions give you specialized capabilities without adding systems to your architecture. The query planner handles complex workloads that neither MySQL nor MongoDB can match.

MySQL is not going anywhere, and it is the right choice when ecosystem fit matters more than database capabilities. WordPress alone ensures MySQL's relevance for decades. For simple CRUD workloads, MySQL's operational simplicity is a real advantage.

MongoDB is the right choice for a narrower set of use cases than its marketing suggests. When you genuinely need document-first data modeling with massive horizontal scale, MongoDB is excellent. But the number of applications that truly need those characteristics is smaller than MongoDB's market positioning implies. Many teams that chose MongoDB for its schema flexibility would have been equally well served by PostgreSQL's JSONB.

The database world has converged. Each of these databases has adopted features from the others -- MySQL added CTEs and window functions, MongoDB added multi-document transactions, PostgreSQL added JSONB. But the implementations are not equal. PostgreSQL's SQL implementation is deeper, its extension ecosystem is broader, and its query planner is more sophisticated. Those advantages compound over the lifetime of an application.

Choose the database that matches your actual workload, not the one that matched your previous company's workload. And if you are unsure, PostgreSQL is the choice you are least likely to outgrow.