Warehouse or Postgres Sizing Worksheet

The question arrives as “have we outgrown Postgres.” It is almost never a question about size. Postgres holds more than the people asking believe, and teams who move for size alone find that whatever was actually slowing them down came along.

This worksheet makes you write down the signal before you write down a vendor. Most of the work is four queries against your own database, read honestly.

Why this exists

The failure mode is a migration argued from row count. It is the one number everybody in the room can produce, so it becomes the argument by default. It is also close to meaningless alone: a billion narrow rows scanned on a partition key is a different problem from fifty million wide rows joined six ways by eleven people at once.

Three signals actually justify the move, and you need at least one of them by name:

• Contention. Analytical scans compete with the application’s own reads and writes on one instance. The symptom is that checkout slows down when somebody opens a report.
• Sources. The questions require joining data that does not live in Postgres and never will — an ad platform, a billing processor, a spreadsheet somebody maintains. You are buying ingestion, scheduling and a transformation layer; the query engine is incidental.
• Unpredictable concurrency. Many readers, each writing their own unbounded query, at hours you do not control. This is where separating storage from compute pays: you stop sizing one box for the worst thing anybody might type.

If you cannot name which of the three you have, you have a tuning problem inside Postgres, and it will follow you across the migration — harder to see, and costing more per hour to look at.

The step that gets skipped is the read replica. Pointing reporting traffic at a replica takes the analytical load off the primary at a fraction of the cost of a migration. A great many “we need a warehouse” symptoms are really “our dashboard is competing with the application.” Try it, measure again, and if the case still holds it is a stronger one.

How to use it

Fill in the measurements before anybody names a product. A vendor named on page one turns every measurement after it into supporting evidence.

Measure at the worst hour, not on average. Contention is bursty by definition, so an average hides precisely the thing you are trying to detect.

Write the counterfactual: what becomes possible that is not today, and who notices. “The data work gets less painful” is a legitimate answer — it is only a problem when something more impressive gets offered in its place.

Ask how the candidate bills — per compute-second, per byte scanned, or a flat instance — and price the most expensive plausible mistake on that model. An unfiltered scan inside a loop is a slow morning on a fixed instance and an invoice on a usage meter. Neither disqualifies anything; not knowing which you signed disqualifies you from the budget conversation.

And cost the migration, not the query engine. The engine is the cheap part. Ingestion per source, the transformation layer, a scheduler, access control, repointing every existing report — that is the project.

Where it goes wrong

The worksheet assumes the choice is open. If a warehouse already exists in the organization and people know how to run it, a second analytics home costs far more than any technical comparison shows, because two homes means two definitions of revenue. That cost is not on this sheet, and it is larger than everything that is.

It does not cover latency either. If somebody needs a number within seconds of the event that produced it, neither side of this comparison is the answer, and this sheet will quietly mislead you about that.

Do not use it to slow a decision already made for other reasons — a hiring plan, a platform standard set above you. Those are real reasons. Write them on the sheet as the reason and skip the measurements, rather than dressing them in numbers that fool nobody.

The measurements also expire. A worksheet from last year is a record of a decision, not evidence for the next one.