HN Debrief

PostgreSQL for Everything

  • Databases
  • Infrastructure
  • Open Source
  • Developer Tools

The post is a broad "just use Postgres" manifesto. It claims PostgreSQL can replace a surprising amount of modern infrastructure, from key-value storage and message queues to full text search, vector search, raw file storage, time series, and even thin microservices. That landed with a lot of sympathy, because many people have watched teams bolt on Redis, Kafka, Elasticsearch, MongoDB, and friends long before the business needed them. The strongest consensus was not that Postgres is literally best at everything. It was that most teams, especially small ones, can get much farther with one boring database than they think, and should add specialized systems only after a real bottleneck shows up.

Defaulting to Postgres can cut real complexity for small teams, but only if you treat it as a starting point with explicit exit criteria. If your product depends on search quality, heavy analytics, strict uptime during scale-ups, or mixed workloads on one cluster, plan the split early instead of assuming Postgres will stay the universal substrate.

Discussion mood

Mostly favorable toward the "start with Postgres" idea, but impatient with absolutist framing. People liked the simplicity and lower ops burden for typical startup workloads, while pushing back on claims that it cleanly replaces Elastic, ClickHouse, Kafka, or object storage at meaningful scale.

Key insights

  1. 01

    Scale assumptions are doing the arguing

    Most of the disagreement came from people imagining completely different systems. For a small B2B app or internal product, a single PostgreSQL instance can cover far more ground than teams assume. For a billion-user consumer system, the same advice is absurd. That framing changes the post from bad doctrine into a decent default for the long tail of ordinary products.

    When someone says a datastore is enough or not enough, ask for workload shape first. Tie architectural decisions to data volume, concurrency, latency targets, and team size instead of arguing from brand names.

      Attribution:
    • 0cf8612b2e1e #1 #2
    • joshuamoyers #1
    • lelanthran #1
  2. 02

    Postgres simplicity ends where tuning begins

    Consolidating on PostgreSQL removes services, but it does not remove database operations. Several comments made the point bluntly that PostgreSQL has many interacting knobs, can be sensitive to long-running transactions, and gets expensive fast when you scale managed instances for p99 spikes. The article's "click a button" scaling line drew skepticism because resizing, failover behavior, and reservation economics are exactly where real production pain shows up.

    If Postgres is becoming your platform, budget for database expertise before the incident that forces it. Track vacuum health, transaction age, scaling times, and cloud cost inflection points while the system is still calm.

      Attribution:
    • sgarland #1 #2
    • ethbr1 #1
    • mooreds #1
    • fabian2k #1
    • encoderer #1
    • majormajor #1
  3. 03

    A Postgres queue is strongest when ops matters more than throughput

    People with scar tissue from RabbitMQ and Kafka argued that a database-backed queue can be easier to run in the environments most companies actually have. PostgreSQL gives you durability, backup, replication, and flexible queue semantics in one place. That is especially attractive when you need fairness across tenants or have to recover whole systems from backups. The hidden win is not raw queue performance. It is avoiding another fragile high-availability system with its own operational playbook.

    If your queueing needs are moderate and tightly tied to application state, prototype it in Postgres first. Reach for a broker when throughput, fan-out, or protocol features are the primary problem, not by default.

      Attribution:
    • tensor #1 #2
    • stackskipton #1 #2
    • tyg13 #1
  4. 04

    Extensions share the database, not the workload

    Comments on TimescaleDB and pgvector highlighted a subtle limit of the "one system" pitch. Extensions may live inside PostgreSQL, but they can still behave like separate engines competing for cache, CPU, and planner attention. Vector search was the clearest example. Once embeddings get large, especially with chunk-level or patch-level indexing for retrieval-augmented generation, latency and cache pressure can wreck unrelated OLTP traffic on the same cluster.

    Treat vector, time series, and similar extensions as workload isolation problems, not just feature checkboxes. If you keep them in Postgres, isolate them onto separate clusters or at least separate capacity plans.

      Attribution:
    • Gluber #1 #2
    • Kinrany #1
  5. 05

    Blob storage hurts backups before it hurts reads

    The most concrete pushback on storing raw files in PostgreSQL was operational, not theoretical. Large BYTEA payloads bloat backups and write-ahead logging, and they can disturb normal query performance by consuming memory and I/O budget. Several comments conceded that lots of small files can work well in-database, but also said the convenience stops being worth it once restore times and storage churn become business problems.

    Store metadata and small artifacts in Postgres if that simplifies consistency. Move large binary assets to object storage before backup windows and restore tests turn into the bottleneck.

      Attribution:
    • sgarland #1
    • Tostino #1
    • mikkelam #1
    • cyberax #1
  6. 06

    Analytics is where specialized engines still win hard

    Even commenters who like pushing Postgres far said OLAP is the clearest boundary. TimescaleDB continuous aggregates help, and newer projects can smooth data movement, but they do not make PostgreSQL equivalent to ClickHouse-style engines operating on columnar data and object storage. One firsthand report described arbitrary analytics queries dropping from a minute to half a second after mirroring data into ClickHouse with little tuning.

    Do not let a successful OLTP setup delay an analytics split longer than necessary. If users are asking exploratory questions across large fact tables, benchmark a columnar engine early instead of endlessly tuning Postgres around the edges.

      Attribution:
    • tpetry #1
    • jeremyjh #1
    • rgbrgb #1
    • ericpauley #1
  7. 07

    SQLite to Postgres is not a free switch

    Several comments pushed back on the common habit of developing on SQLite and deploying on PostgreSQL. The issue is not that SQLite is weak. It is that different typing, query behavior, and adapter quirks can hide bugs until production. People recommended using containers and Testcontainers to run the real database locally and in CI once the app depends on PostgreSQL-specific behavior.

    If production is Postgres, test against Postgres early. Use SQLite as a deliberate product choice, not just as a convenient dev stand-in that can quietly drift from reality.

      Attribution:
    • zelphirkalt #1 #2
    • Merad #1
    • KronisLV #1
  8. 08

    Postgres beat MySQL on trust, not just features

    The side discussion on why PostgreSQL overtook MySQL added useful historical context. MySQL's early speed came with tradeoffs around transactions, constraints, and durability, and some of its biggest operational selling points only looked better before the ecosystem normalized around stronger correctness. Oracle ownership also pushed sentiment. PostgreSQL won not because it was always easier, but because it became the database people trusted to behave like a serious system as their needs grew.

    The popularity of Postgres is partly an ops and governance story, not just a benchmark story. When choosing foundations, factor in ecosystem trust and long-term fit, not just current convenience.

      Attribution:
    • williamdclt #1
    • pandinus #1
    • fabian2k #1
    • jeremyjh #1
    • roryirvine #1

Against the grain

  1. 01

    Calling it one system can hide new complexity

    Pushing search, queues, or analytics into PostgreSQL via extensions and custom patterns can create complexity that is merely relabeled, not removed. The criticism here is not that Elasticsearch or Kafka should be everywhere. It is that saying "it's still just Postgres" can obscure the fact that you now have extension compatibility, provider support gaps, and unusual failure modes that few outside your team understand.

    Count complexity by operational surface area and expertise required, not by process count. A Postgres-centered design stops being simple when only your team knows how the magic works.

      Attribution:
    • devin #1 #2
    • vb-8448 #1
    • dewey #1
  2. 02

    Filesystem beats Postgres for large blobs

    The article's claim that PostgreSQL can outperform raw filesystem access for binary data drew strong skepticism. The pushback was that this may be true for a narrow case involving many small files and favorable caching, but it is not a sound general storage strategy. Once blob volume grows, write-ahead log churn, backup size, and memory pressure dominate the picture.

    Do not generalize from a benchmark that favors one access pattern. Separate small hot artifacts from large cold assets and test backup and restore paths before committing to in-database blobs.

      Attribution:
    • sgt #1 #2
    • sgarland #1
  3. 03

    Distributed KV may outgrow Postgres quickly

    A concrete production case from a team using RocksDB for a hot key-value workload showed where the advice may miss. Their issue was not basic storage. It was horizontal scaling, bursty workers, and zero-downtime deploys around a workload doing thousands of reads per second. In that kind of system, PostgreSQL may be worth testing, but a distributed KV store like TiKV is already closer to the actual problem shape.

    When the bottleneck is distributed write and read scaling for a hot key space, compare Postgres against systems built for that pattern from day one. The right answer may be a KV store, not a more creative schema.

      Attribution:
    • jtwaleson #1
  4. 04

    Managed Postgres still leaves product gaps

    One critique of the article was that the extension story is overstated. Important gaps remain around search ranking like BM25, OLAP features, licensing constraints, and uneven managed-provider support. Even if PostgreSQL can theoretically cover the use case, the version and hosting combinations you can actually buy may not.

    Validate extension availability and license constraints against your exact cloud and compliance setup before you architect around them. A feature that exists in the ecosystem is not the same as a feature you can operate.

      Attribution:
    • cauchyk #1
    • pelzatessa #1

In plain english

BM25 ↩
A widely used ranking algorithm for full-text search that scores documents based on term frequency and rarity.
BYTEA ↩
A PostgreSQL column type for storing binary data directly in the database.
ClickHouse ↩
An open-source column-oriented database designed for fast analytical queries on large datasets.
Elasticsearch ↩
A distributed search engine built on Lucene, commonly used for full-text search and log analysis.
Kafka ↩
Apache Kafka, a distributed system for handling streams and queues of messages between services.
MySQL ↩
A widely used open source relational database management system.
OLAP ↩
Online Analytical Processing, database workloads focused on large-scale querying, aggregation, and analysis rather than frequent small transactions.
OLTP ↩
Online Transaction Processing, database workloads focused on many small, fast, reliable read and write transactions such as app backends or shopping carts.
p99 ↩
The 99th percentile latency, meaning 99 percent of requests are faster than this value and 1 percent are slower.
pgvector ↩
A PostgreSQL extension for storing and searching vector embeddings inside a Postgres database.
Postgres ↩
PostgreSQL, a widely used open source relational database.
PostgreSQL ↩
A widely used open source relational database known for reliability, standards support, and a mature ecosystem.
RabbitMQ ↩
A message broker used to route and deliver messages between systems.
RocksDB ↩
An embedded key-value storage engine optimized for fast local reads and writes.
SQLite ↩
A lightweight relational database that runs from a local file and is often used for simple deployments or embedded apps.
Testcontainers ↩
A testing tool that starts real services like databases in containers for local development and automated tests.
TiKV ↩
A distributed transactional key-value database designed for horizontal scaling.
TimescaleDB ↩
A PostgreSQL extension and platform focused on time-series and analytical workloads.

Reference links

Case studies and essays

Search and text indexing

  • ParadeDB
    Mentioned as an effort to make PostgreSQL more competitive with Elasticsearch-style search workloads.
  • MariaDB full text index overview
    Cited as an example of simple built-in full text search for casual use cases outside PostgreSQL.

Testing and local development

  • Testcontainers
    Recommended for running the same database in development and tests as in production instead of swapping SQLite for PostgreSQL.
  • SQLite strict tables
    Linked in a subthread about SQLite's typing model and whether STRICT mode solves common concerns.

PostgreSQL extensions and adjacent tools

  • PostGIS
    Mentioned as a major omission from the article and a key reason people use PostgreSQL for geospatial workloads.
  • PostgREST
    Suggested as the obvious example for the article's claim that PostgreSQL can replace thin microservices.
  • pgmq
    Named as a PostgreSQL-native queueing tool in the queue discussion.
  • pglite
    Shared in response to a wish for a daemonless PostgreSQL experience more like SQLite.

PostgreSQL docs and operational references