PostgreSQL for everything is a design choice with a price
An argument for using PostgreSQL as the default datastore drew HN into a more precise question: when does operational simplicity beat a specialized system’s advantages?
PostgreSQL can cover relational data, full-text search, queues, and extensions in one familiar operational surface, which is attractive to small teams.
The counterpoint is not that Postgres is weak. It is that a default becomes cargo cult when workload shape, scale, or failure modes have not been examined.
One database can remove several moving parts
PostgreSQL for Everything makes the case for beginning with a database many teams already know. The appeal is not magical universality; it is fewer services to deploy, secure, monitor, and teach.
A default is not an architecture diagram
HN readers generally recognised the operational benefit, while warning against treating a popular tool as an answer before the requirements are clear. Search patterns, write volume, latency needs, and retention rules can make an additional system justified.
The useful rule is reversible simplicity
Starting with Postgres is strongest when the application preserves a path to split out a specialised concern later. That gives a team immediate leverage without pretending its first datastore choice is permanent.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Claude Code users build cleanup passes for its own prose
A Claude Code issue about overly ornate, jargon-heavy output became a catalogue of phrases users now filter after the model writes code or explanations.