One relational database to rule the all

Somewhere along the way "scalable architecture" came to mean bolting on a separate managed service for every job: Redis for caching, SQS for queues, Kafka for events, and a database underneath it all. I've made the opposite mental shift. For most systems, one good relational database does the lot — and the cloud bill thanks you for it.

The default architecture is over-engineered

Four systems means four bills, four sets of credentials, four failure modes, four things to monitor, and four ways for two of them to disagree about the state of the world. You took on a distributed-systems problem to avoid writing a query. For a lot of teams that's a terrible trade made on autopilot because it's what the reference architecture diagram showed.

Postgres already does most of it

• Cache: unlogged tables and materialized views get you a long way before you need a separate cache tier.

• Queue: SELECT ... FOR UPDATE SKIP LOCKED is a robust, transactional job queue in one line. No SQS.

• Pub/sub: LISTEN / NOTIFY handles real-time notifications between workers.

• Event log: an append-only table, plus logical replication if something downstream needs to follow along.

The cost argument

One managed Postgres instance versus a cache, a queue, a broker and a database — each with its own minimum spend and its own per-request pricing. Consolidating doesn't just cut the invoice; it cuts the cognitive load. There's one place the data lives, one thing to back up, one thing to reason about when it's 3am and something's wrong.

When you genuinely outgrow it

Be honest with yourself: at extreme scale you will split things out, and Kafka exists because some problems really do need Kafka. But that's a problem to solve when you have it, with the revenue that comes with it — not a tax to pre-pay on day one when you've got four users and a dream. Start with one database. Add a system when the database is visibly screaming, and not a moment before.