Choosing your production stack after the builder

01

When leaving the builder is the right call

Migration is not a maturity milestone. It is a trade: you spend engineering weeks and take on operational responsibility, in exchange for cost, control, or capability. If none of those three is currently hurting, the trade is bad.

There are four honest triggers. Cost, when the bill grows faster than revenue and the shape of the pricing means that will continue. Capability, when the product needs something the platform cannot do - long-running jobs, websockets, a private network, a specific region. Control, when a customer's security review, an auditor or a regulator asks a question the platform cannot answer for you. And risk, when the entire business depends on a single vendor whose pricing or terms you do not control.

02

Five questions that decide it

Answer these before looking at a single pricing page. In most cases they eliminate three of the five options, and the remaining choice is a coin toss you should resolve with familiarity.

1. What shape is the traffic?

Spiky and mostly idle favours request-priced, scale-to-zero platforms. Steady around the clock favours a rented machine, where a fixed monthly price beats per-request pricing well before you expect it to. Get the real numbers: requests per day and the ratio of peak hour to median hour.

2. What does the work look like?

Short request-response handlers fit anywhere. Anything holding a connection open, running longer than a minute, keeping state on disk, or processing a queue rules out serverless-only hosts immediately - and this is the constraint people discover after migrating, not before.

3. Who owns it on a Tuesday when it breaks?

Name the person. If the answer is “nobody yet” or “we will figure it out”, you have chosen a managed platform whether you admit it now or three incidents from now.

4. Where must the data live, and who has to be satisfied about it?

Enterprise buyers, health and finance regulators and EU data residency requirements all constrain the answer, and they beat your preferences. Get the requirement in writing before you choose, not during the security questionnaire.

5. What is the budget horizon?

Optimising for a bill you will have in three years, at a company that may not exist in three years, is a common and expensive error. Model twelve months out, and prefer options you can leave.

03

Four app shapes and what fits each

04

The options, honestly

Every one of these is a good product. The useful information is not what each does well - the marketing site covers that - but what it costs you and where it stops fitting.

05

The database decision is the bigger one

You will move compute several times before you move data once. Compute is a container and a deploy; data is a migration with a rehearsal, a maintenance window and a rollback plan.

Stay on the builder's bundled database

Often the right first move: keep Supabase or the platform's Postgres, move only the application off. It removes the hosting constraint without touching data gravity, and it is reversible in an afternoon.

Serverless Postgres with branching

Scale-to-zero pricing and a database branch per pull request are real productivity gains. The trade is cold starts on the first query after idle, which matters for a low-traffic B2B app more than the benchmarks suggest.

Managed Postgres from a major cloud

Boring, predictable, well-documented backups, and the answer that satisfies procurement. Costs more at small scale and requires you to think about instance sizes, but nothing about it will surprise you at 3am.

Self-hosted on your own machine

Cheapest on paper and the most expensive in practice unless someone on the team genuinely wants to own backups, upgrades, failover and connection limits. For most teams this is a false economy.

• Put compute and database in the same region. A cross-region round trip per query, multiplied by the queries per request, is the most common self-inflicted latency problem we find after a migration.
• Add a connection pooler before you need it. Serverless compute opens connections faster than a database will accept them, and the failure mode is a full outage rather than a slowdown.
• Whatever you choose, prove the export path works on day one. A database you cannot get data out of is the same lock-in you just paid to leave.

06

A decision path you can follow

1. 1

   Is the current bill small and the product still changing weekly?

   Then stay, and set a numeric trigger for revisiting. Migrating during heavy product change means every regression has two possible causes.

2. 2

   Is the pain ownership rather than cost?

   You may only need your own database, your own secrets and a repository you control - not a new host.

3. 3

   Does anything run longer than a minute, hold a connection, or keep state on disk?

   If yes, remove function-only platforms from the list now. Discovering this after the migration is the single most common regret.

4. 4

   Name the person who owns infrastructure when it breaks.

   No name means you pick the most managed option that satisfies the previous step, and you accept its pricing as the cost of not having that hire.

5. 5

   Collect the external requirements in writing.

   Data residency, certification, network isolation and log retention from customers, auditors or regulators.

6. 6

   Model the bill at ten times current traffic before deciding.

   If two options land within about thirty percent of each other, cost is not the deciding factor.

07

If you move, move in this order

1. 1Secrets and environments first. A clean, per-environment secret store makes every later step reversible and is useful even if you stop here.
2. 2Continuous integration and a reproducible build. Until the app builds identically from a clean checkout, nothing after this is repeatable.
3. 3The database, with a rehearsal. Copy, verify row counts and checksums, measure the cutover window, and write the rollback steps before touching production.
4. 4Background jobs and scheduled work. These are the pieces that quietly do not exist on the new platform, so move them while you still have the old one running.
5. 5The web tier, running in parallel against the same data, verified with real traffic replay or a small percentage of users.
6. 6DNS and CDN last, with a short time-to-live set a day in advance so a rollback takes minutes rather than hours.
7. 7Decommission after a bake period you decide up front - two weeks is typical - not on the day the cutover looks fine.

08

Five ways this goes badly

• Kubernetes for one service and three engineers. The cluster becomes a part-time job that nobody was hired for, and the workload would have run on a container platform unchanged.
• Multi-cloud before product-market fit. You inherit the constraints of both providers and the strengths of neither, at twice the operational surface.
• Rewriting the app during the migration. When something breaks - and it will - you cannot tell whether the cause is the new platform or the new code. Move first, refactor after.
• A big-bang cutover with no rehearsal. The window is always longer than the estimate; the difference between a rehearsed migration and an unrehearsed one is measured in hours of downtime.
• Choosing from a benchmark post rather than your own numbers. Someone else's workload, region and traffic shape tell you almost nothing about your bill.