What is the Gold Layer?
The gold layer is the final tier of a medallion architecture. It holds business-ready tables: aggregates, dimensional models, and metric tables shaped for dashboards, reports, data products, and AI agents. Data flows from bronze (raw, as ingested) to silver (cleaned, deduplicated, conformed) to gold (modeled for a specific use).
Bronze and silver are organized around sources. Gold is organized around questions: revenue by region by day, customer lifetime value, active users by product.
Bronze vs Silver vs Gold
| Bronze | Silver | Gold | |
|---|---|---|---|
| Content | Raw records as ingested | Cleaned, typed, deduplicated, joined | Aggregates, star schemas, metric tables |
| Main users | Data engineers | Engineers, analysts, data scientists | Analysts, BI tools, executives, agents |
| Schema | Close to the source | Conformed across sources | Shaped for consumption |
| Typical history | Append-only, full history | Current state plus SCD where needed | Snapshots or rollups at the grain the business uses |
| Access control | Tightly restricted | Restricted by domain | Broadest read access, often with row and column policies |
Building Gold Tables on Apache Iceberg
In a lakehouse, gold tables are usually Apache Iceberg tables written by Spark, Flink, dbt, or Dremio SQL. A typical gold table is a daily rollup (Spark SQL shown):
CREATE TABLE gold.daily_revenue_by_region
USING iceberg
PARTITIONED BY (months(order_date)) AS
SELECT o.order_date, c.region, SUM(o.amount) AS revenue, COUNT(*) AS orders
FROM silver.orders o
JOIN silver.customers c ON o.customer_id = c.customer_id
GROUP BY o.order_date, c.region;Iceberg features map well to gold-layer needs:
- Snapshots and time travel let you reproduce what a dashboard showed last quarter.
- Atomic overwrites and MERGE let a pipeline refresh a gold table without readers seeing half-written data.
- Branches and tags (in Iceberg and catalogs like Project Nessie) support write-audit-publish, so gold data is validated before it becomes visible.
- Catalog access controls in Apache Polaris or other catalogs restrict who reads which gold tables.
Dimensional techniques still apply. Gold tables often follow a star schema and use slowly changing dimensions where history matters.
Physical Gold Tables vs a Semantic Layer
Every physical gold table is another pipeline to schedule and another copy to keep in sync. Many teams now keep bronze and silver as physical Iceberg tables and define much of gold as views in a semantic layer, materializing only the views that need it for speed (for example with Dremio Reflections). That keeps metric definitions in one place for BI tools and AI agents alike. For the pattern in practice, read What is Three-Tier Data (Bronze, Silver, Gold), Data Modeling for the Lakehouse: What Changes, and What Is a Semantic Layer?.
Frequently Asked Questions
Is the gold layer the same as a data mart?
Close. A data mart is a subject-specific slice of a warehouse; gold tables play the same role in a lakehouse, but they sit on open table formats and can be read by any engine that speaks the catalog.
Should gold tables be aggregated?
Not always. Some gold tables are wide, denormalized fact tables at full grain. Aggregate when the consumers only need the rollup and the savings in query cost are worth the extra pipeline.
Do I need a physical gold layer if I have a semantic layer?
Often only partly. Views in a semantic layer can replace many gold tables; keep physical tables for heavy, frequently used rollups or for data you share outside the platform.
Learn More
To learn more about the Data Lakehouse, read The Lakehouse Built for Everyone by Alex Merced. You can find this and other books by Alex Merced at books.alexmerced.com.