Your backend should be boring: how we choose the cloud and the database

When clients ask what stack we will use for their backend, they sometimes expect a list of fashionable names. The answer is usually duller than that, on purpose. The backend is the part of a product nobody sees and everybody depends on; the best compliment it can get is that nobody has thought about it in months.

The database: Postgres unless there is a reason not to

PostgreSQL is our default for almost everything. It is relational, which is what nearly all business data is; it handles JSON well when you need flexibility; it is mature, well understood, and available as a managed service on every cloud. A managed Postgres — one where backups, failover and upgrades are someone else’s job — removes an entire category of late-night problems.

We reach for something else only with a concrete reason: a time-series database for high-volume sensor data, a search engine alongside Postgres for product search at scale, a cache for hot data that is read far more than written. Each one is added when the need is demonstrated, not anticipated.

The cloud: whichever you already use, otherwise one of the big three

If your company already has an AWS, Google Cloud or Azure account — or your IT team has a strong preference — we use that. Consistency with your existing setup matters more than any technical difference between them. If you are starting fresh, we pick based on what the product needs (Google Cloud when Firebase or its AI services are part of the picture, say) and keep the footprint small enough that moving later is realistic.

What we avoid: spreading a product across several providers because each has one appealing feature. Every extra provider is another bill, another login, another set of credentials to secure.

Serverless, containers or servers

• Serverless functions for things that are event-driven and bursty: webhooks, scheduled jobs, image processing, the contact form on this website. You pay nothing when nothing happens.
• Containers for the main API of a product with steady traffic. Predictable, easy to run locally, easy to move.
• A plain server almost never, these days — but occasionally, for a legacy integration or a licence that requires it.

Most products end up with a container for the API, a handful of functions around it, and a managed database. That shape is not exciting, which is the point.

Things we insist on regardless

• Your accounts, your names. The cloud project is created in your company’s account from day one. We are added as users; we can be removed in a minute.
• Infrastructure as code. The setup is a set of files in the repository, not a sequence of clicks nobody remembers. A new environment can be created by running it.
• Three environments. Development, staging, production. Nothing reaches production without having run on staging first.
• Backups that have been restored. A backup that has never been tested is a hope. We restore from backup once during the project so everyone has seen it work.
• Monitoring that pages someone. Errors, latency and cost alerts, going to a channel a human reads.
• A cost estimate up front, and a cost alert that fires well before it is exceeded.

When boring is wrong

Some products are their backend: real-time collaboration, high-frequency data ingestion, heavy AI inference, very large scale. Those deserve the careful, specific architecture conversations the rest do not. We are glad to have them — but we start from the boring default and justify each departure, rather than the other way round. In a decade of running production systems, that habit has saved more projects than any clever choice.