3 posts tagged with "Medallion"

Re-CASTing the same physical column in every medallion layer feels careful. It is usually how drift multiplies. Bronze casts to decimal. Silver casts again "to be safe." Gold casts a third time and invents an unknown literal with yet another type. Consumers inherit a guessing game.

Type each published column once, as early as you dare (usually bronze, sometimes the first stable clean view). Silver and gold keep aliases, business calculations, and typed unknown-row literals only. UNION alignment casts are the exception, not the lifestyle. Lint the rest.

Figure 1. Type each column once, as early as you dare. Downstream layers should inherit the contract, not reinvent CASTs. Source: Microsoft Learn: copy data activity.

Medallion architecture asks where bronze, silver, and gold live. In Fabric you can answer with many lakehouses or with schemas inside one lakehouse.

That choice leaks into shortcuts, SQL endpoints, notebooks, CI/CD, and how painful renames become later. It is not a folder preference. It is a topology decision.

Figure 1. Lakehouse creation in Microsoft Fabric. Source: Microsoft Learn: lakehouse schemas.

Medallion diagrams still tempt teams to land a physical bronze copy of everything upstream. When the upstream domain already publishes curated Delta in OneLake, that copy is not prudence. It is a second warehouse with a friendlier name.

Bronze can be a contract of shortcuts and thin clean views. Ownership stays with the publisher. Freshness follows the source. Your CI/CD list becomes the shortcut set, not a shadow catalog of cloned tables.

Figure 1. Bronze can be a pointer surface. Prefer OneLake shortcuts over copying bytes the platform already holds. Source: Microsoft Learn: OneLake shortcuts.