Data warehouse, lakehouse, or just Postgres? A sizing guide for mid-size teams

There is a genre of architecture advice written by companies that sell warehouses, and it has convinced a generation of mid-size teams that they are behind if their data does not live in one. Here is the version with no product to sell.

Start by measuring the reporting workload on what you already operate. PostgreSQL may be sufficient; a warehouse or lakehouse may fit better when workload, integration, governance or operating requirements justify it. Lakehouses can hold structured tables as well as other data. These are options to benchmark, not steps every organization must take in the same order.

The honest starting question

Not “warehouse or lakehouse?” but: who is waiting on what? If the concrete answer is “the ops lead waits two days for a report someone builds by hand,” your problem is a reporting problem, and several thousand dollars a month of platform will not fix a two-day human bottleneck any faster than a well-built view on the database you already run.

Ask it about a specific person and a specific Tuesday. What were they deciding, and where did the time go — waiting on a query, or waiting on a human to assemble a spreadsheet? Only one of those is an architecture problem. Usually it is the second, which is why building the report around the one decision it serves beats buying a platform that could theoretically serve all of them.

When Postgres is genuinely the right answer

When reports mainly describe your own operations and the workload is modest, PostgreSQL with suitable views, indexes and a BI tool is a candidate worth testing. A read replica can separate some reporting load, but account for replication lag, recovery conflicts and operating cost. Data fitting in one instance does not by itself prove that architecture meets your needs.

Be precise about where preprocessing runs. A physical PostgreSQL hot standby is read-only: you cannot create or refresh rollups there. Build them on the primary, accepting that extra load, or use a separate writable analytical database with an explicit synchronization process. Materialized views need refreshes, and their freshness must fit the report.

What the numbers actually look like

There is no reliable row-count or gigabyte threshold that chooses the platform for you. Benchmark representative queries, selectivity, row width, available memory, I/O, refresh load and peak concurrency. A slow dashboard may need better queries, indexes, summaries, caching, pooling or a different engine. Twenty simultaneous viewers do not identify the bottleneck by themselves.

Consider a fictional services business with a million job records, nine million line items and half a million invoices. The question is gross margin by crew and week. Compare the current join with an appropriately refreshed summary at that grain in a writable database, then measure query time, refresh time, freshness and production impact. Those are experiment inputs, not a claim that a particular client achieved a one-second query in an afternoon.

Three signals a warehouse earns its keep

Three reasons to investigate a warehouse are reporting contention, recurring cross-system analysis and governed self-service needs. Any of them can justify a comparison; none automatically decides it. Measure the existing bottleneck and compare a targeted improvement with a separate platform, including migration and operating costs.

The middle one is the real trigger, because manual cross-system joins fail quietly: a lookup against a stale export is wrong in a way nobody can see. That is what warehouses are for — columnar speed on big scans, concurrency that does not compete with the application, and one governed place where the systems finally agree.

The managed options are inexpensive to start and priced by use. The real cost is the pipeline work and the modeling discipline — the part that was your actual problem all along. If nobody can trace a number back to the row that produced it, a warehouse reproduces your current ambiguity at higher speed.

What a warehouse adds that you did not budget for

Adopting a warehouse also means operating extraction, transformations, schedules, tests, freshness checks, access control and metric definitions. The balance between infrastructure cost and people’s time depends on the workload and operating model. Metered queries and repeated dashboard refreshes can add cost; read the cloud bill alongside query and usage records rather than assuming which line dominates.

There is also a failure the move creates. The number of places a metric can be defined goes from one to three: the source system, the transformation layer, and the BI tool. That is how two dashboards end up disagreeing a quarter after the migration everyone called a success. Deciding who owns definitions is the thing the platform cannot do for you.

When lakehouse is not a buzzword

A lakehouse can combine open storage, table formats and analytical engines for structured data, mixed workloads and shared access across tools. Apache Iceberg, for example, is explicitly a format for analytical tables. Keeping raw files may help future investigations, but it also needs catalogs, access controls, quality checks, retention and operators. Choose the capabilities you need rather than requiring non-tabular data as an entry condition.

Another option is exporting selected data to columnar files on object storage and querying it with a single-node analytical engine. This can fit some workloads, but include export consistency, access control, refresh, recovery and maintenance in the comparison. It is a managed-or-self-run decision, not free infrastructure or a step every team must take.

“But we will have to migrate later anyway”

A later migration may be necessary, but neither its timing nor its cost is guaranteed. Metric definitions and tests can carry over; SQL dialects, permissions, orchestration and operational assumptions may need rework. Data volume, transfer charges, history validation, downtime constraints and rollback all affect the cost alongside transformation complexity.

The teams who bought the end state on day one migrate too — from their own first attempt, designed before they knew what the business asks on a Tuesday. Premature architecture has the defect of premature optimization: the budget goes to the part you understand least. The board-expects-a-modern-stack objection has a shorter answer still. A report somebody trusts and reads every Monday is more convincing in diligence than a diagram.

What people get wrong first

They move everything. The first migration should be one dataset that answers one question somebody is visibly waiting on, end to end, including the dashboard. Everything else waits until that one is boring.

A vendor reference architecture may solve a larger or different problem. Establish your workload and decide who owns metric definitions before adopting it. Compare a tuned primary, an appropriate reporting database and a warehouse against the same requirements. A replica or rollup can be useful, but neither is a mandatory stop on the way to a sound design.

The sequence, and how you know it worked

Start with a measured reporting problem and move one useful dataset end to end when a new platform is justified. Compare cost, reliability, freshness and operating effort against the baseline. A smaller initial scope can reduce exposure, but savings and cleaner data must be demonstrated rather than assumed.

Write down four numbers before you change anything, then look again in ninety days. How long from a question being asked to an answer somebody trusts. How many reports are still assembled by hand each month. How slow the worst analytical query is, and whether it still runs against production. How many spreadsheets are joining two systems by hand. If those four have not moved, the platform did not work, however modern it is — which is the discipline behind making the numbers hold up.

This sizing conversation is part of my data modernization work. To discuss your workload and the next useful step, start with the discovery call shown on the booking page.

Try this

Choose one slow report and record query time, freshness needs and peak load. On an approved writable test database, compare its current query with an appropriate indexed summary, including refresh cost. A physical standby can read replicated summaries but cannot create or refresh them. Use the measurements to compare options; one fast query does not settle the whole architecture.