PostgreSQL Is Almost Everything You Need. Here Is Where It Is Not.
A technical case for using PostgreSQL as your relational database, your document store, your queue, your search engine, your vector index — and an honest list of the workloads where it is the wrong tool.
This article is not for CTOs. It is for the people who actually have to operate the infrastructure when the architecture diagram becomes a production system.
The thesis is simple. PostgreSQL 17, combined with the modern extension ecosystem and the CloudNativePG operator, can replace a significant portion of the specialised data infrastructure that most organisations currently run as separate systems. Not all of it. The article is honest about where Postgres loses. But the surface area that Postgres covers credibly in 2026 is larger than most architectures reflect, and the operational and financial cost of running half a dozen specialised data stores when one well-tuned Postgres cluster would do is rarely justified by the actual workload requirements.
The following is what Postgres replaces, what it does not replace, and what the alternative actually costs.
What Postgres replaces credibly
Oracle Database for relational workloads
This is the headline claim and it deserves evidence rather than assertion. A TPC-C benchmark published in August 2025 comparing Oracle Standard Edition against vanilla PostgreSQL on identical hardware showed PostgreSQL achieving roughly 108% higher new orders per minute and 126% higher transactions per minute than Oracle SE. That is not parity. That is Postgres winning outright on a workload Oracle has historically owned.
The honest caveat: this benchmark is against Oracle SE, not Enterprise Edition. Oracle EE with RAC, In-Memory, Partitioning, and the full options stack will still win on certain narrow workloads — extreme OLTP at very high concurrency, partitioned analytics at petabyte scale, active-active clustering with sub-second failover. If your workload genuinely requires those capabilities, Postgres is not yet a complete replacement. For the vast majority of applications running on Oracle today, it is.
MongoDB and other document stores
Postgres JSONB with GIN indexes handles document workloads at performance comparable to dedicated document databases for most query patterns. Schema flexibility, nested queries, partial updates — all supported. The operational advantage of not running a separate MongoDB cluster, with its own backup strategy, replication topology, and failure modes, is significant for teams that are not large enough to specialise.
Redis for queue workloads, pub/sub at modest scale, and session storage
This is where I push back on my own thesis honestly. Postgres SKIP LOCKED handles work queue patterns elegantly. LISTEN/NOTIFY handles pub/sub for moderate message rates. Session storage in a Postgres table with appropriate indexing performs adequately for most web applications. What Postgres cannot do is replace Redis as a high-throughput in-memory cache serving a million operations per second with sub-millisecond latency. Redis was built for that workload and Postgres was not. If your access pattern is “cache the result of an expensive query and serve it back at extreme rates” — keep Redis. The Redis Operator on Kubernetes is mature and the operational overhead is low. Use the right tool.
Elasticsearch for full-text search
Postgres tsvector with proper indexing handles full-text search for most application requirements. Combined with pg_trgm for fuzzy matching and unaccent for normalisation, the result covers the search needs of typical web applications, internal tools, and content platforms. Elasticsearch wins decisively for log search at scale, complex aggregations across billions of documents, and search-as-the-primary-product workloads. For everything else Postgres is enough and removing Elasticsearch from the stack eliminates a meaningful operational burden.
Pinecone, Weaviate, and dedicated vector databases
pgvector, particularly the recent versions with HNSW indexing, delivers production-grade vector similarity search inside Postgres. The benchmarks against dedicated vector databases show pgvector competitive at moderate scale and slower at extreme scale. For RAG pipelines, semantic search over corporate document repositories, and most embedding-based workloads, pgvector inside the existing Postgres cluster is the correct architectural choice. The data is already there. The backup strategy already covers it. The replication already handles it.
What Postgres does not replace and where I push back hardest
Object storage
Do not put files in bytea columns. The temptation is real because it eliminates a separate system and keeps everything transactional, but the consequences are operationally severe. Large objects in Postgres bloat your WAL stream, destroy your backup performance, slow down replication, and make point-in-time recovery painful. The right architecture is S3-compatible object storage for the blob, Postgres for the metadata and references.
The recommendation here is Garage — a Rust-based S3-compatible object store designed for self-hosted deployments. It is significantly simpler to operate than MinIO, has no licensing surprises, runs comfortably on commodity hardware, and integrates cleanly with CloudNativePG for WAL archiving. SeaweedFS and Ceph RGW are also production-grade alternatives depending on scale and operational preferences. None of them are Postgres and none of them should be.
High-volume log ingestion and search
Postgres can ingest logs. With pg_partman for automatic partitioning and BRIN indexes for time-series access patterns, it handles moderate log volumes acceptably. But log workloads are characterised by extreme write rates, append-only patterns, and analytical queries over time ranges — exactly the workload pattern that purpose-built systems handle an order of magnitude more efficiently. ClickHouse, Loki, or even Vector to flat files indexed by date are the right answers for serious log infrastructure. Postgres is not.
Time-series at extreme scale
TimescaleDB is a Postgres extension and an excellent choice for time-series workloads up to a point. Beyond that point — billions of data points per day, sub-second aggregation queries across years of data — InfluxDB, ClickHouse, or VictoriaMetrics outperform Postgres-based solutions. For monitoring infrastructure of any organisation operating at scale, Prometheus with appropriate long-term storage remains the right answer.
Graph workloads at scale
Postgres recursive CTEs handle graph traversals adequately for shallow queries on modest datasets. Neo4j and dedicated graph databases dominate at depth and scale. If your application is fundamentally a graph problem — fraud detection, recommendation engines, social network analysis at millions of nodes — Postgres is the wrong primary store.
Active-active multi-master replication across regions
Postgres has logical replication and there are extensions like pgEdge that add multi-master capability, but Oracle GoldenGate and dedicated distributed databases like CockroachDB or YugabyteDB still handle this pattern more cleanly. If your application genuinely requires writes accepted on multiple continents simultaneously with conflict resolution, Postgres is workable but not the obvious choice.
What the alternative actually costs
Oracle Database Enterprise Edition list price is $47,500 per processor licence as of the 2026 list. The processor metric uses the Oracle Core Factor Table — Intel Xeon and modern AMD EPYC processors carry a 0.5 factor, meaning each physical core counts as half a processor licence.
The realistic case study published by Redress Compliance: a modern server with 32 cores at a 0.5 Intel core factor equates to 16 processor licences — a base cost of $760,000 before any options, support, or discounts. Annual support at 22% adds $167,200 in year one, rising by 8% per year thereafter.
That is one server. Before Partitioning, RAC, In-Memory, Advanced Security, or Active Data Guard — each of which carries its own per-processor list price, often comparable to the base Enterprise Edition cost.
Enterprise customers do not pay list. Typical negotiated discounts run 40 to 70% below list, but the negotiating position is fundamentally weak because Oracle holds an audit hammer over every customer. The Oracle License Management Services team exists specifically to identify unlicensed feature usage and convert it into multi-million dollar audit claims.
The same workload on PostgreSQL with CloudNativePG: zero licence cost, zero audit risk, and an operator that passed 132 million downloads in 2025 and applied for CNCF incubation status on 12 November 2025. The hardware budget that was paying for sixteen processor licences now pays for engineering capability, additional capacity, or simply does not get spent.
For a single mid-size database server, the year-one Oracle cost is roughly equivalent to the salary of three senior database engineers. Over a five-year hardware refresh cycle accounting for support escalation, the difference funds an entire database team plus infrastructure plus consulting engagements with room to spare.
CloudNativePG operational reality
The operator handles the lifecycle: bootstrapping, streaming replication with configurable synchronous or asynchronous topology, automated failover with quorum-based consensus, rolling minor version upgrades, declarative point-in-time recovery, scheduled and on-demand backups via either the Barman Cloud Plugin to S3-compatible storage or CSI volume snapshots for storage classes that support them, connection pooling via PgBouncer with the integrated Pooler resource, and Prometheus metrics out of the box.
One feature deserves explicit attention because it changes how applications can be architected against the cluster. CloudNativePG automatically exposes three distinct Kubernetes services for every cluster: a read-write service pointing exclusively at the current primary, a read-only service pointing exclusively at the hot standby replicas, and a read service that load-balances across any instance including the primary. Application code that distinguishes between read and write paths can scale read traffic horizontally by pointing read queries at the read-only service, with no application-level awareness of which physical node is serving the query, no manual reconfiguration on failover, and no additional infrastructure beyond what the operator provisions by default.
This is the pattern that Oracle Active Data Guard charges separately for and that most managed services either do not expose cleanly or require additional configuration to enable. The operator provides it as a primitive. Applications written to take advantage of it scale read capacity by adding replica pods — a single line change in the cluster spec.
The 2025 hardening work specifically addressed split-brain scenarios — a primary isolation check that allows a primary node to self-fence on losing connectivity, and a quorum-based failover mechanism that ensures failover only proceeds when a majority of nodes agree. These are the failure modes that historically separated managed services from self-hosted Postgres in serious operators’ minds. They are addressed.
A practical three-node CloudNativePG cluster with synchronous replication, automatic failover, daily backups to Garage, and PgBouncer pooling is approximately 200 lines of YAML. The same architecture in raw Patroni plus PgBouncer plus pgBackRest is several thousand lines of configuration, runbooks, and operational tooling that someone has to maintain. The operator earns its place in the stack.
One storage architecture deserves explicit mention because it changes what the cluster can do operationally. ZFS on local NVMe as the underlying storage for the Postgres data directory delivers transparent compression that typically reduces storage footprint by 40–60% for relational data, end-to-end checksumming that catches silent disk corruption Postgres alone cannot detect, and instant copy-on-write snapshots that enable clone-and-test workflows for production data without copying a single byte. The historical Postgres community concern about ZFS under Postgres centres on double-buffering between the ZFS ARC and the Postgres shared buffers — a legitimate concern in a single-node context. In a three-node CloudNativePG cluster with synchronous replication, the memory overhead is absorbed by the architecture and the benefits apply to all three nodes simultaneously. Tune primarycache=metadata on the Postgres dataset and limit zfs_arc_max appropriately and the double-buffering argument loses most of its force.
The honest caveat: CloudNativePG is at CNCF Sandbox level pending incubation. It is production-grade in the practical sense — used at scale, hardened, actively developed — but it does not have the multi-decade institutional inertia of Oracle’s tooling. For organisations whose risk register requires that inertia, this is a real consideration. For everyone else it is a theoretical concern that the actual operational record does not support.
The architectural recommendation
For a typical production stack of moderate scale:
PostgreSQL with CloudNativePG as the primary relational store, document store via JSONB, queue infrastructure via SKIP LOCKED, full-text search via tsvector, vector search via pgvector, and time-series for moderate volumes via TimescaleDB. One operator, one backup strategy, one replication topology, one set of monitoring dashboards.
Redis with the Redis Operator for high-throughput caching only — the workload it was actually built for.
Garage for S3-compatible object storage, with Postgres holding metadata and references.
ClickHouse or Loki for log infrastructure if log volumes are non-trivial.
Prometheus with appropriate long-term storage for metrics.
This is a complete production data layer that runs on commodity Kubernetes — vanilla, in the cloud or on bare metal — with no licensing exposure, no vendor audit risk, and operational complexity that a competent infrastructure team can master and maintain.
The alternative — Oracle for the database, Mongo for documents, Redis for everything Redis-shaped, Elasticsearch for search, Pinecone for vectors, S3 for objects, separate vendor relationships and separate operational models for each — is what most organisations actually have. It is more expensive in licence costs, more expensive in operational overhead, more expensive in failure mode complexity, and more expensive in the human cost of context-switching between half a dozen specialised systems that one well-operated Postgres cluster would have replaced for most of what they actually do.
Postgres is not the right answer for everything. But it is the right answer for more than your current architecture probably reflects, and the gap between what it does well and what your stack assumes it cannot do is wider than most engineering teams have looked at recently.
Look at it.
Sugau works with engineering teams reducing data infrastructure complexity through CloudNativePG, vanilla Kubernetes, and self-hosted alternatives to commercial database licences. The conversations start with what you actually run, what it actually costs, and what could be consolidated without compromising operational integrity. sugau.com