Is PostgreSQL enough for modern application architecture?

A manifesto-style website arguing for PostgreSQL as a one-stop-shop for application needs sparked a classic Hacker News debate about architectural simplicity versus the performance gains of specialized systems.

The proposition

A new single-serving site, postgresisenough.dev, argues that for a wide range of applications, developers can and should replace specialized systems like Redis, RabbitMQ, and Elasticsearch with features already available in PostgreSQL. The site acts as a central artifact for a long-simmering architectural philosophy. A subsequent Hacker News thread, posted by user 'b-man' in early July 2026, gathered over 400 comments debating the merits of this bundled approach. The discussion pitted the pragmatism of a simplified stack against the conventional wisdom of using the "right tool for the job."

Side A: The great rebundling

Proponents argue that modern PostgreSQL is a powerful, extensible platform capable of handling tasks far beyond simple data storage. For many teams, especially smaller ones, the operational complexity of managing a half-dozen distinct infrastructure services is a significant tax on productivity.

This side's argument, championed by the website and echoed by users like 'jlong' on the thread, centers on simplification. Why run a separate Redis instance when Postgres has robust key-value support and caching mechanisms? Why manage RabbitMQ when you can implement a reliable job queue with SKIP LOCKED and NOTIFY? The logic is that the performance difference is often negligible for all but the highest-scale applications, while the benefits of a single, transactionally consistent system are immense. "The cognitive overhead of learning, deploying, monitoring, and securing five different systems is a real cost," one commenter argued, "especially when your database can already do 80% of what those systems offer." This approach reduces points of failure, simplifies development environments, and leverages the deep expertise many teams already have in SQL.

Side B: The right tool for the job

The opposing view holds that this consolidation is a false economy that trades short-term simplicity for long-term scalability and operational headaches. This camp, represented by comments from users like 'dbsmith' and an anonymous engineer from a large cloud provider, contends that specialized systems exist for a reason: they are purpose-built and highly optimized for specific workloads.

Their steelman argument is that while Postgres can be a queue, it is not a very good one compared to RabbitMQ or SQS, which are designed for high-throughput, at-least-once delivery, and complex routing. Similarly, while you can perform full-text search in Postgres, it will not outperform a dedicated Elasticsearch or OpenSearch cluster on large datasets. This side warns of the "single, overworked monolith" problem. By loading every function onto the primary database, you create a single point of failure and a bottleneck that is difficult to scale. As one user put it, "You're putting all your eggs in one basket, and then asking that basket to also be a toaster and a refrigerator." The argument is that separating concerns allows each component to be scaled, managed, and replaced independently, a necessity for growing applications.

What's underneath

This is not a debate about technical possibility, but about the definition of "scale" and the corresponding trade-offs. Side A is implicitly designing for the 90% of applications that will never reach FAANG-level traffic. For them, operational simplicity and speed of development are the most critical resources. Their definition of scale is about team efficiency and time-to-market. Side B operates from a perspective where component-level performance and independent scalability are non-negotiable, assuming a trajectory toward high traffic and complexity. They are optimizing for a future where a 10ms latency difference in a cache lookup matters. Both sides are correct, for their own contexts. The disagreement arises when one side presents its context-specific solution as a universal best practice.

The investor read

The "Postgres is enough" movement signals a growing counter-current to the last decade's unbundling of developer tools and the resulting "SaaS sprawl." For investors, this highlights a market demand for capital-efficient stacks, particularly in the bootstrapped and seed-stage ecosystems. It suggests a potential ceiling on the total addressable market for hyper-specialized infrastructure tools that target startups. This trend favors platforms that offer integrated, "good enough" solutions over a constellation of best-of-breed point solutions. It's a leading indicator of a market segment prioritizing lower burn rates and reduced operational complexity over bleeding-edge performance.

Pull quote: “This is not a debate about technical possibility, but about the definition of "scale" and the corresponding trade-offs.”