Postgres as a Default Is a Discipline

Every few months someone writes a clean, slightly stubborn essay that amounts to: what if we just used PostgreSQL for more of the architecture? Queues. Documents. Full text. Geospatial. Analytics adjacent to the app. Job state. Feature flags. The comment section then splits into two camps: people who have been burned by polyglot sprawl, and people who have been burned by one database asked to do circus tricks. I land closer to the first camp, with scars from both.

The real cost was never the second database

The second database looks cheap on a whiteboard. It is "just Redis." It is "just Elasticsearch." It is "just another managed service with a cute dashboard." The cost arrives later as operational fan-out. Separate backup stories. Separate failure modes. Separate auth models. Separate local-dev myths. Separate "who understands this at 2 a.m." lists. Separate schema migrations that drift out of sync with the system of record.

If your company is large enough, that sprawl can be rational. Specialization wins at scale. If your company is still finding product shape, every new datastore is a bet that you already know your access patterns and staffing model. That bet is often wrong.

Postgres as a default is not romance about SQL. It is a forcing function: make the data model honest before you multiply the moving parts.

What "for everything" should actually mean

It should not mean stuffing every workload into one process until the vacuum settings become folklore. It should mean:

• prefer one transactional core until a measured pain appears,
• use extensions and proven patterns before new infrastructure,
• keep derived systems explicitly derived,
• and treat specialized stores as exits you earn, not toys you collect.

I have watched teams adopt a queue because a table felt unfashionable. Then they spent months recreating transactional outbox semantics they already had. I have also watched teams insist on Postgres for a search workload that genuinely needed a purpose-built engine. Dogma is bidirectional. The discipline is evidence. Latency histograms. Lock contention. Operational toil. Not vibes from a conference hallway.

Where Postgres earns the center of gravity

For product applications with relational truth, rich constraints, and humans who need to debug with SQL, Postgres remains an unusually good gravity well. Foreign keys are documentation that runs. Transactions collapse classes of distributed regret. The ecosystem is mature in the ways that matter when money and identity are involved. If I can keep user state, billing-adjacent records, and workflow status in one place with clear invariants, I sleep better. Caching can sit in front. Search can sit beside. Streams can fan out. The core stays boring and queryable. That architecture is less impressive in diagrams. It is more impressive in incident reviews.

A personal rule of thumb

I ask one question before adding a new store: what failure becomes easier, and what failure becomes harder? If the new system makes one happy-path metric prettier while making consistency and recovery harder, I wait. If it removes a real, measured ceiling that Postgres cannot reasonably clear, I adopt it without guilt. "Postgres for everything" is a slogan. Useful slogans are really about sequencing. Start centered. Specialize on purpose. Keep the system of record boring enough that the product can be interesting.

A cultural benefit

There is also a cultural benefit I do not want to underweight. Shared SQL literacy is one of the last cross-role languages left in many companies. Support can inspect rows. Analysts can validate a metric. Engineers can reproduce a bug without learning a fifth vendor dialect. When every concern gets its own store, that shared literacy fragments into guild knowledge. I do not need every team to worship one database. I need more teams to stop confusing optionality with progress. The best stack is often the one your future teammate can still explain with a whiteboard marker and a straight face.