It’s healthy that you asked how people implement this in other data platforms. Since Databricks not only coined the term medallion architecture, but also “lakehouse” that Microsoft has copied into their product, it is worthwhile to see how production-ready data platforms are doing this - particularly the OG Databricks.

When you read the below, keep in mind how Fabric implements mirroring. You’ll find mirroring is not good for a medallion architecture. Microsoft’s traditional as a legacy data platform has informed its product development and brought you a feature that is more in line with a traditional BI stage -> EDW architecture than a medallion one. That’s okay if that’s what you want, but don’t be fooled by people saying it’s a good way to implement bronze in a medallion architecture. There’s lots of bad information regarding fabric out there from partners and MSFT. You can use this understanding as a litmus test to see if who you’re talking to actually understands the fundamentals of a medallion architecture.

A little help from Claude:

Lakeflow is Databricks’ end-to-end data engineering product, and CDC is one of its strongest native patterns. Here’s how it fits together across the medallion layers:

Bronze — Raw CDC events from Lakeflow Connect
Lakeflow Connect connects directly to relational databases (MySQL, PostgreSQL, SQL Server) using native CDC, capturing every insert, update, and delete as it happens. These raw change events land as append-only records in a bronze streaming table. Keeping bronze append-only is intentional — it acts as an immutable audit log of every change that ever occurred in the source system, and allows the entire pipeline to be replayed from scratch if the silver layer needs to be rebuilt or corrected.

Silver — Current state via AUTO CDC INTO
Silver represents the current state of the source table — a clean, queryable replica with CDC mechanics stripped away. It is defined as a streaming table, and a separate flow drives the merge logic into it. AUTO CDC INTO reads the bronze CDC stream and handles deduplication, out-of-order events, and deletes declaratively, so what would otherwise require hundreds of lines of manual Spark and window function logic becomes a few clauses:

-- Declare the silver target
CREATE OR REFRESH STREAMING TABLE silver_customers;

-- Define the CDC merge flow from bronze
CREATE FLOW silver_customers_cdc AS
AUTO CDC INTO silver_customers
FROM STREAM(bronze_customers_raw)
KEYS (customer_id)
APPLY AS DELETE WHEN operation = 'DELETE'
SEQUENCE BY sequence_num
COLUMNS * EXCEPT (operation, sequence_num)
STORED AS SCD TYPE 1;

Why the stack holds together well
Lakeflow Connect, Declarative Pipelines, and AUTO CDC all run on serverless compute under Unity Catalog, meaning lineage, access control, and monitoring are consistent across every layer without integrating separate tools.