A practical blueprint for building lakehouse data platforms that support both finance-grade reporting and product analytics at scale.
The lakehouse pattern — columnar storage on object store, ACID table format on top, separated compute — is now mature enough to replace the warehouse + lake split that most enterprises built between 2015 and 2020. This post is the blueprint we use when an enterprise wants one platform that supports both finance-grade month-end reporting and product analytics, without two duplicated copies of the same data.
Why this works now
Three things changed: Delta Lake and Iceberg matured into production-stable table formats with proper time travel and schema evolution; cloud query engines (Databricks SQL, Snowflake on Iceberg, Trino) reached warehouse-class performance on lakehouse storage; and dbt + semantic layers (Cube, Lightdash) made governed metrics affordable without a $1M BI license.
Platform flow
Bronze — the landing zone
Bronze is raw, append-only, schema-on-read. Whatever the source produces, we land it with metadata (source, ingestion timestamp, batch ID) and never modify it. This is the audit floor — if anything goes wrong downstream, bronze is the source of truth we replay from.
Ingestion uses CDC (Debezium for transactional sources, Fivetran for SaaS) into Kafka, then a streaming job lands batches into bronze every 1–5 minutes depending on freshness requirement.
Silver — cleaned and conformed
Silver applies schema, deduplicates, conforms timestamps to UTC, resolves identities (one canonical customer ID across sources), and applies data quality checks. This is where the data becomes usable.
DQ checks run as pipeline gates: failures block promotion to silver and notify the data owner. We use Great Expectations for declarative checks ("order_total must be > 0", "customer_id must exist in dim_customer").
Gold — the semantic layer
Gold is where finance and product analytics finally agree on what "active customer" means. Metrics are defined once in dbt + a semantic layer (we use Cube) and consumed from BI tools, notebooks, and the product itself.
This is the most important architectural commitment: no SQL that defines a business metric lives outside the gold layer. BI dashboards reference metrics; they don't recompute them.
Schema evolution and contracts
Operational source schemas change. We protect downstream consumers with data contracts: each silver table has a schema definition file owned by the producing team, versioned in git, with a CI check that breaks the PR if a breaking change ships without a contract bump.
Breaking changes get a 30-day deprecation window. Non-breaking changes (additive columns) ship freely.
Lineage — dashboard to source
When a CFO asks "why did this number change", you need lineage in seconds, not days. dbt's auto-generated DAG + a lineage tool (OpenLineage, Atlan, or DataHub) gets you dashboard → mart → silver → bronze → source system in two clicks. Without this, trust in the platform erodes within a quarter.
What we'd do differently
On one engagement we tried to land all sources into bronze with strict typing. It was slow, fragile, and held up integrations. Switching to schema-on-read in bronze (JSON or schema-less Parquet) and enforcing types only at silver simplified the platform massively.
Closing
A lakehouse done right collapses two-platform overhead (warehouse + lake) into one platform that serves governed reporting and ad-hoc analytics from the same physical data. The win is operational simplicity and a single source of truth — not raw query speed.
