Medallion architecture for event data and where the layers earn their keep

Somebody puts three coloured boxes on a slide, labels them bronze, silver and gold, and the room nods. Two weeks later the same team cannot agree which box the registration export lands in, whether the deduplicated contact list is silver or gold, and what is supposed to happen to the file the scanning vendor sent twice.

Medallion architecture for event data is worth adopting and it answers fewer questions than the diagram implies. The layers are a filing convention with a rebuild rule attached, and the value shows up in different layers at different points in a show portfolio's life.

What the three layers are, in their authors' words

Databricks, which named the pattern, still defines it on the glossary page it maintains in 2026 as "a data design pattern used to logically organize data in a lakehouse, with the goal of incrementally and progressively improving the structure and quality of data as it flows through each layer of the architecture".

Its description of bronze is the operative one: "The Bronze layer is where we land all the data from external source systems. The table structures in this layer correspond to the source system table structures 'as-is,' along with any additional metadata columns that capture the load date/time, process ID, etc." Silver is where "the data from the Bronze layer is matched, merged, conformed and cleansed ('just-enough') so that the Silver layer can provide an 'Enterprise view' of all its key business entities, concepts and transactions". And on gold, Databricks says plainly: "We see a lot of Kimball style star schema-based data models or Inmon style Data marts fit in this Gold Layer of the lakehouse."

Microsoft's Fabric documentation, revised in February 2026, states the bronze rule more bluntly than Databricks does, instructing teams to "Store everything exactly as it arrives. No changes are allowed." The same page says that in the bronze layer "you store data in its original format".

Two vendors describing the same three layers in compatible terms is about as close to a settled convention as this corner of the industry gets, and the convergence is worth leaning on when somebody in review wants to invent a fourth layer.

What one edition actually lands

Concreteness helps here, because the diagram is abstract and a show is not.

One edition of one B2B exhibition produces roughly six raw files. The registration export from the registration platform. The badge scan export from the access control vendor. The exhibitor contract list from the sales system. The session programme from the conference tool. The lead retrieval export, which usually arrives from a different vendor than the access control one. And the floor plan allocation, which is often a spreadsheet.

Those six land in bronze untouched, one folder per edition, with a load timestamp and the file's own checksum recorded alongside.

Silver turns them into conformed entities. A person record with one row per resolved human. A company record with one row per resolved organisation. A session record. An exhibitor record keyed to the contracted company. This is where the portfolio work happens, and where the same buyer registering under two email addresses becomes one person, which is a large enough problem to have its own set of conformance rules.

Gold is the star schema: three fact tables for this show, holding registrations, badge scans and session entries, plus the dimensions they share. For one edition that is 12,400 registration rows, 38,900 scan rows and 12,200 session entry rows, or 63,500 fact rows in total. Across a portfolio of 8 shows with 5 years of history, that is 40 editions and about 2,540,000 fact rows, which is a small database by any measure that matters.

What an annual cadence changes about the layers

Almost every published description of this pattern assumes data trickling in. Streams, change feeds, hourly micro batches, silver tables updated incrementally as bronze grows.

An exhibition does not behave that way. Registration accrues over about nine months, then 38,900 scans arrive inside 96 hours, then the source systems go quiet for eleven months. That shape changes three things about how the layers are built.

Partitioning by edition stops being an optimisation and becomes the organising key. Every table in every layer carries an edition key, and each layer's unit of work is one edition rather than one day, which makes reloading a single show a bounded operation instead of a surgical one.

Silver gets rebuilt whole rather than merged into. Conforming 12,400 registrations against a portfolio of 40 editions takes minutes, so the incremental machinery that a daily pipeline needs is unnecessary complexity here, and rebuilding removes a whole class of drift between what the conformance rules say today and what they said when a row was written.

And the layers age at different rates. Gold gets rewritten whenever a metric definition changes, which is often. Silver gets rewritten whenever the matching rules improve. Bronze never changes, which is the point of it, and it is the layer whose loader will have quietly stopped working by the time you need it.

Does an eight show portfolio need three layers?

The layers pay off on different schedules, and pretending otherwise oversells the pattern to a team who will judge it in month two.

Bronze pays immediately, at the first edition, and it pays for one reason. Every other table in the warehouse can be thrown away and rebuilt from it. That property is what makes a schema change survivable, and without it the first time somebody redefines verified attendance you are negotiating with a vendor about whether they still hold last year's export.

Silver starts earning at the second show. With one show there is nothing to conform, and a conformance layer over a single registration file is ceremony. With two shows in the same vertical you immediately have the same company written two ways and the same buyer registered twice, and the cost of resolving that inside each report is higher than the cost of resolving it once.

Gold earns its keep the first time somebody asks a portfolio question. How many people came to more than one show. What the overlap is between the exhibitor bases of two events. Those questions are answerable from a conformed star schema and painful from anything else.

The honest reading is that a single show with a single annual registration file should build bronze and gold and skip the middle layer until there is a second show. That is a two layer medallion, it looks wrong on the slide, and it is the correct amount of structure for that business.

Which layer does the deduplication belong in?

This is the argument that actually consumes design review time, and there is a test that settles most of it.

Ask whether the layer could be deleted and reproduced exactly from the layer beneath. If yes, the transformation belongs there. If no, it belongs further down, or it does not belong in the warehouse at all.

Deduplication of people fails that test in bronze, because merging two registration rows destroys information that cannot be recovered from the merged result. So it sits in silver, and bronze keeps both rows. Currency conversion on exhibitor contract values also sits in silver, because the rate used has to be recorded and applied consistently across shows. Renaming a column from delegate_type to registration_type is a silver job. Computing scans per exhibitor is gold, because it is a report definition and report definitions change.

The case teams most often get wrong is filtering. Somebody drops test registrations and staff badges during the bronze load, because they are obviously junk. Then a year later the fraud question comes up, or somebody wants to know how many staff badges were issued against the contract allowance, and the rows are gone. Filtering is a silver decision and bronze keeps everything, including the rows that are certainly wrong.

What the pattern does not decide for you

Medallion says where things live. It says nothing about what they mean, and that is a much larger body of work.

It does not tell you the grain of a fact table, which is the single decision that determines whether two reports agree, and which needs an explicit written statement per table. It does not tell you how to key an edition, or whether a job title change should overwrite or create a row. It does not tell you what verified attendance is. Three layers of badly grained tables is the same defect propagated three times with more infrastructure around it.

It also does not decide retention. Bronze grows forever by default, and a show that runs once a year has a genuinely different retention calculation from a business with a daily pipeline, both analytically and legally. That calculation gets its own treatment in the retention decision for raw files.

Where the pattern stops earning

The rebuild property that justifies bronze is a claim, and most teams have never tested it.

An immutable raw file you cannot parse today is not a rebuild path. The vendor changed the export format between editions. The 2023 file is cp1252 with no header row and the 2024 file is UTF-8 with one. Keeping the bytes without keeping the loader that understood them leaves you with an archive rather than a warehouse input, and finding that out during a backfill is expensive enough to have its own planning problem.

The second limit is that the layer names invite a false sense of quality. Silver is defined as conformed, so people treat silver tables as trustworthy, and a badly written conformance rule produces a silver table that is confidently wrong at higher volume than the bronze it came from. Layer position is not evidence of correctness, and the layer boundary is exactly where a data quality check should sit rather than where one is assumed to have happened.

Take the raw files from your most recent edition, put them in a folder named for that edition, and try to rebuild one gold fact table from them with the current code. If the rebuild produces a different row count than the table already in production, that difference is the real state of your bronze layer, and it is worth knowing before you draw the diagram. Whatever you learn belongs in the data platform conventions.