Stop/Start on burstable Postgres: what it saves, what it breaks
Switching the database off overnight is the first cost lever everyone reaches for on a burstable tier. It genuinely works — on a smaller share of the bill than people expect, and it quietly takes a set of availability assumptions with it.
On a learning platform MVP we costed and architected this year, the client asked a reasonable question: nobody uses this thing between midnight and eight, so why are we paying for the database then? The answer is that you mostly aren't — and understanding which part of the bill keeps running is the difference between a cost model that holds and one that embarrasses you in month two.
What actually stops billing
On a managed Postgres flexible server, the bill separates into compute, storage, and backup. Stop/Start pauses the first one only. Provisioned storage bills continuously whether the server is running or not, and backup storage keeps accruing against your retention window. Nothing about stopping the server makes your data cheaper to keep.
That has a consequence people miss: on the smallest burstable sizes, compute is not the dominant line. It is the line you can most easily halve, which is not the same thing. Turning a burstable instance off for two-thirds of the day does not cut the database bill by two-thirds; it cuts the compute component by roughly that, against a storage and backup floor that does not move at all.
Savings are bounded by the compute share of the bill, not by the hours you switch off. Model the floor first; the schedule is the smaller variable.
This is why we built the Kratoz cost model with on-hours per day as an exposed input rather than baking in an assumption. The client can move the dial from twenty-four down to eight and watch how little the total moves once the floor is visible — and can see the exchange rate applied separately, so a currency shift is never mistaken for a cost overrun. A model that shows the shape of the curve is worth more than a model that produces one confident number.
What it breaks
Resume is not instant. A stopped server takes minutes to come back, and during that window connections do not queue — they fail. If anything can hit the API outside on-hours, the first user of the day gets an error page, not a slow response. That is a product decision disguised as an infrastructure setting.
Everything scheduled has to know. Nightly jobs, report generation, integration syncs, CI runs that apply migrations against a shared environment, synthetic availability checks — each one assumes a database. Any of them firing during off-hours either fails silently or wakes the server and quietly cancels your savings.
Monitoring turns into noise. An availability test against a deliberately stopped environment pages someone at 3am. If planned downtime is not encoded in the alerting, the team learns to ignore alerts — a far more expensive outcome than the compute you saved.
Stopped is not indefinite. The platform will restart a stopped server on its own after a bounded period, so Stop/Start is a schedule, not an off switch. Treat it as automation you own, not a state you leave things in.
Burstable has its own cliff. B-series instances run on CPU credits: they perform well until the credit balance is exhausted, then they throttle. That behaviour is independent of Stop/Start but gets blamed on it, because both produce "the database was slow this morning." If you are running a burstable tier, instrument credit balance before you start tuning schedules — otherwise you will optimise the wrong thing.
Where we use it, and where we refuse
Dev, test and UAT: yes, on a schedule, automated, with alerting muted for the window and CI aware of it. Demo environments and pre-launch MVPs where the user population is known and local: yes. It is genuinely the highest-return lever available on a non-production estate, precisely because nobody is watching.
Production: no — not because the saving isn't real, but because you have replaced an availability guarantee with a schedule that a single misjudged timezone invalidates. If production spend is the problem, the answers are right-sizing against observed utilisation, reserved or committed capacity, storage lifecycle rules, and moving off burstable when the credit cliff starts showing up in your P95. Those are boring and they compound. Uptime games do neither.
The general principle we hold to: Stop/Start is a budget instrument for environments nobody depends on. The moment someone depends on the environment, the correct lever is sizing, not scheduling.