Choosing boring: why our default is Postgres, a monolith, and one queue

When we scope a new product, our starting architecture is almost always the same: Postgres, a monolith, and one queue. Not because it is fashionable, and not because it photographs well in a systems diagram, but because every component you add is a system you now operate at 3 a.m.

Boring technology has a specific virtue: its failure modes are known. Postgres has been failing in well-documented ways for thirty years, and the fixes are a search away. The exciting alternative fails in ways you get to discover personally, in production, while your customers watch.

Why Postgres. At the scale most products actually reach, Postgres is also your search engine, your JSON store, your analytics database, and, with a careful schema, a perfectly good queue for low volumes. Each of those jobs could be a separate system. Each separate system is another set of credentials, another backup policy, another version upgrade, another way for data to disagree with itself.

Why a monolith. One codebase, one deploy, one place to look when something breaks. A refactor is a function call moving between files, not a coordinated release across six repositories. Microservices solve real problems, but they are organizational problems, and you need the organization first. Splitting a five-person product into services is paying rent on an office building to host a desk.

Why one queue. Some work genuinely must happen outside the request: emails, exports, webhooks, long-running jobs. That work goes to one queue with one set of retry semantics that everyone on the team understands. The second queue arrives when the first has a measured, documented reason to be insufficient.

The honest part is the exit criteria. Defaults are defaults, not dogma, and we deviate when the problem forces it: true realtime fan-out at scale, heavy media processing pipelines, hard multi-region requirements, a read pattern Postgres genuinely cannot serve. The discipline is writing down which forcing condition applies before adding the component, so the architecture stays a set of decisions instead of a collection of enthusiasms.

Senior architecture is mostly visible in what it declines. Anyone can add a system. Knowing why you did not is the part that keeps a product cheap to run and possible to change two years later.