There is a version of this decision that happens in conference talks, where a lakehouse is the modern answer and a warehouse is the legacy one. There is another version that happens in a mid-size company with four data engineers, forty dashboards and a new AI initiative, where the question is really "what will still be running well in three years with the team we have?" This post is about the second version.
The quarter we lost
A client with a healthy warehouse asked us to help plan for AI workloads: document embeddings, model features, some semi-structured event data. A well-meaning internal proposal argued for moving everything to a lakehouse on object storage. The debate ran for a quarter. Meanwhile, the AI initiative waited, the warehouse kept working, and the team learned a great deal about table formats they did not yet need.
When we finally sat down with the actual requirements, the answer was: keep the warehouse for the structured, governed data that ran the business; add object storage with an open table format for the documents, embeddings and event streams; and connect the two through the warehouse's own external-table support. It took three weeks to build. The quarter of debate had been about a migration that nobody needed.
The question is not which architecture is better. It is which workloads you actually have, and which tool each one is already good at.
The questions that settle it
What are the workloads? Governed reporting and finance-grade metrics favour a warehouse: strong SQL, access control, mature tooling. Large volumes of semi-structured or unstructured data, machine-learning features, and streaming events favour object storage with an open format. Most mid-size teams have both, in that order of importance.
Who will run it? A lakehouse gives more control and asks for more engineering: table maintenance, compaction, catalog management, cost governance. A managed warehouse trades control for a team that does not need to think about those. Be honest about the team you have, not the one in the proposal.
What does governance look like today? If access control, lineage and data classification already work in the warehouse, moving to a system where they must be rebuilt is a step back for the business even if it is a step forward for the architecture.
What does the AI work need? Embeddings and document stores, feature tables, and training data extracts usually want object storage and open formats. They rarely need the finance data to move with them.
The hybrid most teams end up with
The architecture that has held up across our engagements is not a purist one. A managed warehouse remains the system of record for structured, governed data. Object storage with an open table format holds documents, embeddings, events and model artefacts. A catalog spans both so that lineage and access rules are visible in one place. Transformations run in one framework across both, and the AI systems read from wherever the data they need lives.
This is less exciting than a migration and much more likely to be finished.
Security is where migrations get expensive
The cost that proposals underestimate is not moving the data. It is rebuilding the controls: row and column permissions, masking of personal data, audit logging, retention. A warehouse that has these working represents years of decisions. A new platform starts with none of them, and the AI workloads, which handle documents and personal data, are exactly the ones that need them most. Whatever you choose, plan the controls first and the storage second, and use a catalog that lets the same policy apply in both places.
Cost, honestly
Object storage is cheap per terabyte and a warehouse is not. But the total cost includes the engineers who maintain the platform, the compute that queries it, and the time the business waits for the migration. On mid-size teams, the cheapest architecture is usually the one that lets the current team do the most with the least new operational burden, and that is rarely a wholesale move.
Purposefully chosen
The right answer for most mid-size teams is to add what the new workloads need next to what already works, and to make the decision in weeks with a workload inventory rather than in quarters with a vendor deck. Save the migration for the day the warehouse actually stops being the right tool for the data that runs the business. That day may come. It is not usually today.
- Inventory workloads: governed reporting, semi-structured data, AI features, streaming.
- Match each to the tool that already handles it well.
- Count the team, not the roadmap.
- Plan controls first: permissions, masking, lineage, retention.
- Add object storage for AI workloads; keep the warehouse for the business.
- Span both with one catalog and one transformation layer.