Forum Discussion
Medallion Archtecture
- Hi icassiem,No silly questions at all. These are exactly the right questions when you start thinking about data architecture instead of only solving one report.The goal is to avoid a spaghetti architecture later.I would separate two things:1. What you know today2. What might happen laterDo not over-design only based on assumptions. But also do not name everything so narrowly that it becomes hard to grow.For your case, I would choose a balanced approach:Workspace:ws-analytics-devws-analytics-prodThen keep the domain in the item/table names:lh_silverwh_goldTables or schemas:silver_product_customersilver_product_salesgold_dim_customergold_fact_salesIf Product becomes big enough later, or IT/Finance needs different ownership/security/lifecycle, then split into domain workspaces later:ws-product-analytics-prodws-it-analytics-prodSo yes, start with what is factual today, but use naming that does not block future growth.For the medallion question:Yes, it is still medallion even if the physical items are different.Medallion is a logical pattern, not a rule that every layer must be the same technology.Example:Silver = LakehouseGold = WarehouseOptional forecasting output = Gold Lakehouse or ML output tableThat is still a medallion architecture because the logic is:Source → cleaned/standardized → curated/business-readyI would not create lh_gold unless you have a clear need for it.For now, I would keep it simple:API / JSON / CSV→ lh_silver→ wh_gold→ semantic model→ Power BI / Copilot narrativesAdd lh_gold later only if forecasting/Python needs curated Delta output before loading to the Warehouse.Architecture criteria should be based on:- ownership- security- lifecycle- performance- data reuse- maintainabilityNot only “possible future request”.
Hi,
The answer you received is solid, and I’d just reinforce one key point from a practical architecture perspective: in Fabric, you don’t need to force a single choice between Lakehouse and Warehouse for your Gold layer , it’s very common (and recommended) to use both depending on the workload. Keeping Silver in a Lakehouse is absolutely the right approach for API and semi-structured ingestion, and for Gold you can split responsibilities: use Gold Lakehouse for curated Delta tables, Python-based transformations, and forecasting scenarios, and use Gold Warehouse only where you need structured SQL marts, dimensional models, or BI-friendly serving layers. For Copilot narratives specifically, what matters is your semantic model and Power BI layer, not whether the data sits in Lakehouse or Warehouse. On naming and workspace design, avoid naming based on a single use case like “Product” , instead use a broader domain-based naming convention (e.g., per business domain) and keep items clearly structured (silver/gold separation at item level, not workspace per layer). Given you’re on F2, keep things simple initially (one workspace per domain, minimal duplication), and only introduce Warehouse or additional layers when you have a clear consumption need.