Architecture
Five questions before you commit to a lakehouse
The lakehouse is a kit, not a product. Five readiness questions that separate teams who benefit from open tables from teams who inherit a part-time job.
The Cloud Practice1 min readArchitecture
The technology argument for lakehouses is largely settled: open table formats matured, the engines cross-read each other, and Databricks now supports Iceberg fully. What is not settled, and what we test in every assessment, is whether a specific team is ready to operate one. Five questions decide it.

Who runs table maintenance? Compaction, snapshot expiry, metadata cleanup. On a warehouse these are the vendor's job. On open tables they are yours, on a schedule, forever. Name the owner or stop here.
Do you have more than one engine that matters? The lakehouse's core payoff is many engines on one copy of the data. If everything you run is SQL analytics in one tool, a warehouse delivers the same outcome with less surface.
Where does access control live? Catalogs carry this now, and the answer must be specific: which catalog, integrated with which identity provider, administered by whom.
Can you state the exit cost from your current platform? Not philosophically. In engineer-months, with the extract inventory to back it.
Has anyone on the team operated one before? Firsthand experience changes estimates by integer multiples. For calibration, the principal's warehouse build for an insurance group, coordinating 150+ daily extracts across five companies, is the scale of operational detail a real platform accumulates. A lakehouse adds table-format operations on top of all of it.
Three or more confident answers: proceed, and sequence the work. Fewer: a warehouse plus open formats at the edges serves you better this year, and there is no shame in the boring option that ships.