What a lakehouse is, what the layers mean, how bad data is handled, who can read what, what it costs to run, and what you get at handover. Written for the person who has to approve the project, not only the person who builds it.
A lakehouse stores data as open files in cloud storage (Delta Lake tables on Azure storage, in our case) and runs warehouse-style SQL, pipelines and machine learning on top of them. You keep the cheap storage and open formats of a data lake and get the reliability of a warehouse: transactions, schema enforcement, time travel. Databricks is the platform we use to run it.
Three layers with three promises. Bronze lands every file or event exactly as it arrived, with the time it arrived and where it came from; nothing is dropped. Silver applies rules: fix what can be fixed, quarantine what cannot, drop only exact duplicates. Gold holds one table per business question, shaped for the questions people ask. The lakehouse walkthrough shows all three on 4.3 million public taxi trips.
They are counted and kept, never deleted silently. Each silver rule is written as an expectation, so every run reports how many rows failed it. Rows that fail go to a quarantine table with the reason attached. In the public taxi file for June 2025, 6.4% of rows carry a negative fare (refunds and voids); if you sum revenue without handling them the total is wrong by millions. That is the kind of thing quarantine makes visible instead of invisible.
Landing uses Auto Loader with schema evolution on, so a new column is added to bronze instead of failing the run at 3 am. A renamed or re-cased column shows up as an unmapped name in silver's checks and raises an alert rather than quietly producing empty values. Both cases are tested on purpose before launch, because they are the first things that break in production.
Unity Catalog, with grants by group. Analysts read gold, because that is the only layer with a promise attached. Engineers read silver and the quarantine table, because that is where the questions are. Nobody writes by hand: pipelines run as a service principal, and the audit log says so. Row-level filters are added where the business needs them. Lineage from source to report comes with it.
Mostly what you let it. The same daily pipeline costs a small fraction on a job cluster that starts, runs for minutes and terminates, compared with an all-purpose cluster left running through the working day because someone might have a look. Auto-termination and a budget alert that reaches a person are the first two settings we change in a new workspace. We do not publish client numbers; the walkthrough shows the relative gap.
Not always. If your data is a few well-behaved tables and the warehouse is fast and affordable, keep it. A lakehouse earns its place when files and events arrive in volume, when sources change shape, when the warehouse bill grows faster than the business, or when the same data has to feed reports, models and an application. The scoping call is where we say which case you are in, in writing.
A first lakehouse with a handful of sources, the three layers, governance, a reporting model and monitoring is usually a matter of weeks, delivered in weekly increments with a demo each week. Adding a source to an existing platform is days. The written quote carries the timeline, and it is fixed for the agreed scope.
Through a semantic model built on the gold layer, as a star schema with measures, incremental refresh and aggregation tables for the pages everyone opens. Direct Lake or import mode depending on size and latency needs. The Power BI page covers the model in detail.
Because it runs the whole shape on one platform: landing, cleaning, governance, SQL, pipelines and models, with open Delta tables underneath so the data is never locked in. Microsoft Fabric is a reasonable choice for teams already standardised on it, and we work with it. Where a client's data fits in a single file, DuckDB on a laptop is the honest answer and we say so.
Yes. The first week is reading, not changing: what runs, what it costs, what fails, what has no owner. You get a written list of findings ranked by risk, then a plan. Rewriting everything is rarely the recommendation; adding expectations, quarantine, monitoring and cost controls to what exists usually is.
The code in your repository, the pipelines deployed and scheduled in your workspace, a runbook per alert, a document that explains each table and each rule, cost and freshness dashboards, and a recorded walkthrough. Then a month of support. The test of a good handover is that your team can add a source without us.
Describe it in three lines. We reply within a working day with questions and a first view of the fix.
