Forum Discussion

icassiem's avatar
icassiem
Post Prodigy
1 month ago
Solved

Medallion Archtecture

Good day, Kindly advise on what the modern archietecture for a fabric medallion of dilver and gold only, currently reading API & possibly semi structured data too so my research says silver is my l...
data engineering
  • Parchitect's avatar
    Parchitect
    1 month ago
    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 today
    2. What might happen later

     

    Do 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-dev
    ws-analytics-prod

     

    Then keep the domain in the item/table names:
    lh_silver
    wh_gold

     

    Tables or schemas:
    silver_product_customer
    silver_product_sales
    gold_dim_customer
    gold_fact_sales

     

    If Product becomes big enough later, or IT/Finance needs different ownership/security/lifecycle, then split into domain workspaces later:
    ws-product-analytics-prod
    ws-it-analytics-prod

     

    So 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 = Lakehouse
    Gold = Warehouse
    Optional forecasting output = Gold Lakehouse or ML output table

     

    That is still a medallion architecture because the logic is:
    Source → cleaned/standardized → curated/business-ready

     

    I 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 narratives

     

    Add 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
    - maintainability

     

    Not only “possible future request”.
SoniAnkit's avatar
SoniAnkit
New Member
1 month ago

Hi icassiem,

You are on the right track. In Microsoft Fabric, a common approach is to keep the Silver layer in a Lakehouse using Delta tables, especially for API and semi-structured data.

For the Gold layer, you can move to a Fabric Data Warehouse if your goal is to build curated data marts, support SQL analytics, create forecasting tables, and leverage Copilot capabilities. Many organizations use a hybrid approach:

  • Silver: Lakehouse (Delta)

  • Gold: Fabric Data Warehouse

For naming conventions, I recommend organizing workspaces by business domain or product area rather than by medallion layer. For example:

Workspace: ProductAnalytics

  • lh_product_silver

  • dw_product_gold

  • semantic_product_sales

  • nb_product_forecasting

This provides flexibility for future expansion and avoids creating too many workspaces, which is especially important with an F2 capacity.

For your use case (API ingestion, semi-structured data, analytics, and forecasting), the following architecture works well:

API/Semi-structured Data -> Silver Lakehouse -> Gold Fabric Data Warehouse -> Power BI/Copilot/Python Forecasting

This approach aligns with current Microsoft Fabric best practices and provides good scalability for future requirements.

Regards,
Ankit