Sooner or later someone on the board asks: are we building a data warehouse, a data lake or a lakehouse? It is usually someone who has just come back from a conference, or who has three quotes in hand, each with a different architecture diagram. The answer rarely depends on technology. More often it depends on which decisions your company needs to support and who will maintain the thing.
Below we sort out the terms and show where the bill comes from. At the end we suggest how to choose so that you do not pay for a platform nobody uses.
Three terms, one muddle
A data warehouse is a database designed for analytics. Data sits in tables with a fixed schema, and reports and dashboards run fast even when dozens of people use them at once. It is a proven model, good for finance and sales. It copes less well with raw files, logs, images or documents, and at large volumes it can get expensive.
A data lake is a cheap file store (usually cloud object storage) where you drop everything in its original form. The schema is applied only when you read the data. The flexibility is huge, but without discipline a lake quickly turns into a swamp: nobody knows what is current, who owns the data, or whether two reports count the same thing.
A lakehouse combines traits of both. Data sits in a cheap, open layer of files, with a table layer and a catalogue on top that add transactions, change history and access control. Its authors described it as an answer to the awkward setup of two separate systems, where data has to be copied from the lake to the warehouse and someone has to make sure the two copies agree.
In practice the boundaries blur. Warehouses can now read files from the lake, and lakehouse platforms offer SQL and dashboards. So "what is what" matters less than "what do I need to do with the data".
Iceberg and Delta: why they matter for your wallet
The heart of a lakehouse is an open table format. The two you meet most often are Apache Iceberg and Delta Lake. Both add to plain files what we know from databases: safe writes, schema changes without rewriting the whole table, and "time travel", meaning you can read a table as it was a week ago or undo a bad load.
For the board, one thing counts: data in an open format is not locked inside a single product. Different engines can read it. Iceberg is supported by Spark, Trino and Flink, among others, while Delta Lake, developed under the Linux Foundation, works with a wide range of engines, including Snowflake, BigQuery, Athena and Microsoft Fabric. The larger cloud and platform vendors now support Iceberg to a greater or lesser degree, and Delta offers a UniForm mode that lets Iceberg clients read Delta tables. Support changes fast and is uneven (especially for write features), so before you buy, check the vendor's documentation rather than a slide from a presentation.
This does not mean an open format removes vendor lock-in. The catalogue, permissions, orchestration tools and your team's know-how remain. The format lowers the cost of leaving, but does not bring it to zero.
Where the bill comes from
In most cloud solutions you pay separately for storage and for compute. Storage is cheap. Compute makes the bill.
There are two popular models. In the first, as in Snowflake, you start virtual compute warehouses that burn credits while they run. The biggest cost lever here is idle time: a cluster left on over the weekend costs the same as one that is crunching numbers. In the second, as in BigQuery on-demand mode, you pay for the amount of data scanned, so one badly written query without a date filter can cost more than a whole normal day of work. BigQuery also offers capacity reservation in a slot model, which gives predictability at the expense of flexibility.
The third component is transfer. Loading data into the cloud is usually free, but taking it out of a region or to another vendor is not. With large volumes, egress fees can change the outcome of an offer comparison. So the question "where does the data physically sit and who will read it" should be asked before you sign, not after the first invoice.
Current price lists come straight from the vendors, and third-party write-ups (such as the cost comparison of Snowflake, BigQuery and Redshift) show what the total cost of ownership really is. The numbers in sales presentations rarely include idle time, team effort or migration.
When plain Postgres is enough
A less glamorous but honest answer: very often Postgres is enough. If your analytical data fits in hundreds of gigabytes, a handful of people run reports and the sources are two or three systems, a separate data platform is overkill. Add tools like DuckDB, which crunch analytics quickly on a single machine, and extensions that embed that engine in Postgres.
Still, the slogan "big data is dead" comes largely from companies that sell tools for small and medium datasets. The claim is sensible for many teams, but it is not a law of nature. The point at which Postgres stops being enough depends on concurrency, the kind of queries, and whether you want to combine structured data with files and streams.
Signs it is time to move beyond Postgres: reports load the production database, queries run for hours, you need change history at scale, or data arrives in formats that do not fit in tables.
The comparison in one table
| Warehouse | Data lake | Lakehouse | Postgres (+ DuckDB) | |
|---|---|---|---|---|
| Data type | Structured | Any files | Structured and files | Structured |
| For whom | Analysts, BI | Data scientists, engineers | Both groups | Small team |
| Concurrent BI | Very good | Weak without add-ons | Good, depends on the engine | Good up to medium scale |
| Storage cost | Medium | Low | Low | Low |
| Compute cost | Depends on the model | Depends on the engine | Depends on the engine | Fixed, predictable |
| Team requirements | Moderate | High | High | Low |
| Lock-in risk | Medium to high | Low | Low to medium | Low |
This is a simplification, not a verdict. A specific product can look different from its category.
Questions that settle the choice
Instead of asking "which technology is best", answer five questions.
- Volume: how much data is there today and how much in two years? Gigabytes are a different conversation from tens of terabytes.
- Latency: is a report on Monday morning enough, or do you need decisions within seconds, in logistics or energy for example?
- Team: who will maintain it? A platform that needs four engineers when you have one is a mistake, whatever its merits.
- Compliance: where must the data sit, who has access, and what about personal data? In healthcare and finance this is often the first criterion, not the last.
- Vendor lock-in: how hard and expensive would it be to leave? Open formats and standard SQL help, but test it in practice, on a small sample.
If the answer to most of these is "little, slow, small team", start with something simple. If you have data from many systems, streams, files and AI needs next to classic BI, a lakehouse starts to make sense.
Typical mistakes
First: building the platform before the use case. The company buys licences, hires a team, draws an architecture on paper, and a year later it turns out no department has an urgent question the platform answers. Infrastructure without a user is a cost, not an asset.
Second: no governance. Without a data catalogue, dataset owners and clear metric definitions, every architecture, even the most modern, ends up as a pile of contradictory numbers. Governance is not a stage for later. Start small: a list of key datasets, a named owner for each, one definition of revenue.
Third: the cost of unused clusters. Test environments running around the clock, compute warehouses sized too big "just in case", no automatic shutdown. In the projects we run, this is the most common source of wasted spend and the easiest to fix: budget limits, alerts and automatic suspension after a few minutes of inactivity.
Fourth: migrating everything at once. Moving a whole warehouse in one project usually ends in delays, and sometimes in the business losing trust in the data.
Recommendation: start with one use case
Pick one concrete business question whose answer is worth real money. For example: which orders are late and why, what the true margin on a product is after logistics costs, when energy consumption crosses the contractual threshold.
Then do three things with it. Collect only the data you need. Choose the simplest architecture that can handle it, even if that is Postgres. Set success metrics and a monthly cost with a cap. After two or three months you have a working result, real cost figures and an idea of what is missing. Only then is the decision about a lakehouse, a warehouse or something in between based on facts from your company, not on vendor presentations.
Open data formats and the separation of storage from compute let you add further use cases without rebuilding the foundations. If you want to talk about which case to start with at your company, we are happy to sit down over the specifics.
Sources
- Apache Iceberg, project documentation
- Delta Lake, project website
- Armbrust et al., Lakehouse: A New Generation of Open Platforms (CIDR 2021)
- MotherDuck, The Data Warehouse TCO: Snowflake, BigQuery, Redshift
- Google Cloud, BigQuery pricing
- DS Stream, Data Warehouse vs. Data Lake vs. Lakehouse
- GraphScope, Why DuckDB Is Such A Good Database Product
