Last week, I read The Register’s coverage of MongoDB CEO Chirantan “CJ” Desai telling analysts that a “super-high growth AI company … switched from PostgreSQL to MongoDB because PostgreSQL could not just scale.” (The Register)

I believe you can show the value of your own technology without tearing down another. That is really what this post is about.

I run a company that lives inside PostgreSQL production issues every day. We deal with performance, HA and DR design, cost optimisation, and the occasional “we are down, please help” call from a fintech or SaaS platform. My perspective comes from that hands-on work, not from a quarterly earnings script.

Scaling stories are always more complex than a soundbite

When a CEO says, “This AI customer could not scale with PostgreSQL,” a lot of details disappear:

• What did the schema and access patterns look like?
• How was the application managing connections and transactions?
• What was running underneath? Cloud managed PostgreSQL, a home-rolled cluster, or something else?
• Were vertical and horizontal scaling options fully explored?
• Did the team have PostgreSQL specialists involved, or was everything on default settings?

None of that reduces MongoDB’s strengths. Document databases are excellent for certain workloads: highly variable document shapes, rapid iteration, and development teams that think in JSON first. MongoDB has earned its place.

My concern is with the narrative that PostgreSQL, as a technology, “cannot scale,” especially given that it is the most popular database among professional developers and has overtaken MongoDB in the DB-Engines ranking over the last decade. (DB-Engines)

The method for calculating this ranking is detailed here: https://db-engines.com/en/ranking_definition.

Every database has strengths. Every database has trade-offs. Real-world results come from matching those strengths to the workload and from running the system with care.

What PostgreSQL offers for scaling

PostgreSQL scaling is a spectrum. When someone says “it does not scale,” the real question is usually “which dimension of scale, under which design?”

1. Vertical scale: one node, serious throughput

A single well-configured PostgreSQL instance on modern hardware handles:

• Hundreds of thousands of transactions per second
• Tens of terabytes of data on a single node

This is not a marketing copy; PostgreSQL consultants have demonstrated these ranges repeatedly in the field.

In practice, many SaaS and fintech workloads have lived entirely within this vertical envelope for years. A typical high-end OLTP node may look like:

# Excerpt from postgresql.conf on a busy OLTP systemshared_buffers       = '32GB'Effective_cache_size = '96GB'work_mem             = '64MB'Maintenance_work_mem = '4GB'max_connections      = 500wal_level            = replicamax_wal_senders      = 20synchronous_commit   = on

Layer that on top of fast NVMe storage, tuned Linux parameters (huge pages, I/O schedulers, TCP settings), and connection pooling (PgBouncer or Pgpool-II), and you already have a very capable single node.

2. Horizontal scale: scale-out patterns that teams use today

When a single node envelope is not enough, PostgreSQL offers multiple, well-understood patterns:

Read scaling with replicas

• Native streaming replication provides multiple read replicas.
• Connection routing at the application or proxy layer directs reads to replicas and writes to the primary.

Partitioning and sharding

Start with native partitioning:CREATE TABLE events (    tenant_id    bigint,    created_at   timestamptz,    payload      jsonb) PARTITION BY RANGE (created_at);

CREATE TABLE events_2025_q4 PARTITION OF events FOR VALUES FROM (‘2025-10-01’) TO (‘2026-01-01’);

This reduces index and table bloat, keeps hot data in smaller structures, and improves cache efficiency. From there, you can shard by tenant or region using extensions such as Citus, which turn PostgreSQL into a distributed cluster while keeping SQL semantics.

Specialised distributed PostgreSQL services

The ecosystem now includes fully managed, distributed PostgreSQL or PostgreSQL-compatible systems:

• AWS Aurora
• Google AlloyDB
• Microsoft HorizonDB on Azure
• Third-party systems such as PGD, TimescaleDB, YugabyteDB, CockroachDB

Even The Register article that quoted the “could not scale” remark listed these services as answers to concerns about PostgreSQL scalability. (The Register)

These platforms exist precisely because organisations want PostgreSQL semantics and ecosystem benefits at a very large scale.

None of this is science fiction. It is what many of us run for clients every day.

AI workloads are still workloads

A lot of the rhetoric here anchors on “AI workloads,” as if that label alone demands a completely different class of database.

When you strip away the hype, most AI-heavy platforms combine:

• High-volume event ingestion (traces, actions, telemetry)
• Vector search over embeddings
• Metadata and configuration storage
• Analytical queries over usage and performance

PostgreSQL handles these patterns very well when you apply the right architecture:

• The pgvector extension provides vector types and indexes.
• Time-series and event tables benefit from partitioning and, if appropriate, time-series extensions. (Tiger Data)
• Read replicas and distributed variants cover high-volume read access and multi-region requirements.
• Strong transactional semantics and mature tooling simplify the “critical path” parts of AI platforms, such as billing, entitlements, and configuration.

MongoDB also effectively supports AI workloads when the document model aligns with the system’s needs. The real design work lies in balancing transactional consistency, query patterns, schema evolution, and operational comfort for the team.

“AI workload” is a description of behaviour, not a free pass to declare one database category the winner.

What I see in real PostgreSQL production environments

Because I run a PostgreSQL-only services firm, I tend to see systems when they are under pressure:

• A fintech running a three-node PostgreSQL cluster sustaining high write rates and achieving 99.99% availability with automated failover and tested DR.
• A last-mile delivery platform built on Odoo and PostgreSQL, where careful indexing, parameter tuning, and query refactoring improved throughput by several orders of magnitude without a move to any new database.
• Multi-region architectures where we measured replication behaviour across regions and tuned topology, sync levels, and application retry logic until lag and failure modes stayed inside business SLAs.

In each case, PostgreSQL scaled just fine once the architecture matched the problem:

• Hot paths isolated into lean tables.
• Background jobs separated from request paths.
• Connection limits enforced with pooling.
• Replication configured deliberately instead of left at defaults.

The blocker was rarely PostgreSQL as a core technology. The blocker was design, implementation, or operational discipline.

Where MongoDB is a strong choice

To keep this honest: there are scenarios where MongoDB is a very reasonable first choice, even in systems that already use PostgreSQL:

• Highly polymorphic document payloads with frequent structural changes, where strict relational modelling would slow teams down.
• Use cases dominated by document-level access with minimal cross-document joins.
• Teams with deep MongoDB experience and an existing operational toolchain that they trust.

Choosing MongoDB in those scenarios is smart engineering.

My issue is with narratives that imply PostgreSQL is fundamentally unable to scale, rather than saying, “For this workload and this team, MongoDB was a better fit.”

Our industry benefits greatly when leaders frame their success that way.

Scaling is an engineering discipline, not a brand attribute

I believe responsible comparisons look more like this:

1. Start from the workload

• Request rate, throughput, and latency targets

• Data model, relationships, and query patterns

• Consistency and durability requirements2. Consider team capabilities

• SQL and relational experience

• Existing operational muscle around PostgreSQL, MongoDB, or both

• Appetite for running distributed systems3. Match patterns, then products

• Vertical scale, replicas, and partitioning may cover years of growth.

• When you truly outgrow those, consider distributed PostgreSQL services or specialised databases, including MongoDB, that address the specific gap.4. Benchmark honestly

• Use the same hardware class, realistic schemas, and realistic queries.

• Measure p95 and p99 latencies, plan stability, failure behaviour, and operational effort, not only headline QPS.

This is where meaningful decisions happen, far away from any sentence that says “X cannot scale.”

For CTOs and Database Engineers reading this

If you are responsible for a PostgreSQL deployment and you are now second-guessing your choices because of a quote from an earnings call, you are exactly who I am writing for.

A few practical questions you can ask yourself before considering a move from PostgreSQL to anything else:

• Have we exhausted vertical scaling on a well-tuned primary with fast storage?
• Are we using read replicas where they make sense?
• Is our schema designed for our access patterns, or is the database carrying application-layer problems?
• Have we explored partitioning for our largest, hottest tables?
• Are we testing and measuring, or reacting to anecdotes?

If the answer to several of these is “no,” you still have a lot of PostgreSQL headroom.

My closing thought

You can show MongoDB’s value without framing PostgreSQL as a dead end. You can show PostgreSQL’s value without dismissing MongoDB.

As practitioners, we owe it to the people who depend on these systems to keep the conversation grounded in architecture, workload patterns, and operational reality, rather than headlines.