Forum Discussion
SQL Strategy
Hi everyone,
With the growing number of database technologies available, I'm curious how organizations decide which database should support different workloads.
When working with Microsoft Fabric, how do you decide whether data should remain in an operational database or be moved into Fabric for analytics?
I'd appreciate hearing the decision-making process you've found most effective.
Great question here is the approach I recommend based on my knowledge:
Keep data in the operational database when:
- Sub-second latency and high write concurrency are required.
- Strong ACID and application-enforced row-level security are non-negotiable.
- Workloads are transactional and customer-facing.
Move or mirror into Fabric when:
- Workloads are analytical (scans, aggregations, historical trends).
- Data from multiple sources needs to be blended for BI or ML.
- A governed semantic layer on OneLake (Direct Lake + Power BI) is needed.
- Long-term retention or cross-domain sharing via Purview is in scope.
Choose the integration pattern by latency:
- Near real-time ->Fabric Mirroring (Azure SQL, Cosmos DB, Snowflake, PostgreSQL)
- Streaming -> Eventstream / Real-Time Intelligence
- Minutes–hourly -> Dataflows Gen2 / Pipelines
- Data already in ADLS/S3/GCS 0 -> OneLake Shortcuts (virtualize, don't copy)
Key principles:
- Keep one copy of truth in OneLake, let Warehouse, Lakehouse, KQL, and Power BI read the same data.
- Never run analytics directly on production OLTP.
- Prefer Mirroring and Shortcuts over ETL wherever supported.
- Govern centrally through OneLake and Purview.
In short: operational databases run the business; Fabric analyzes it. The decision comes down to workload type, latency SLA, and integration method.
Thank you.
Srikanth Cheri
CST Team.
3 Replies
Great question here is the approach I recommend based on my knowledge:
Keep data in the operational database when:
- Sub-second latency and high write concurrency are required.
- Strong ACID and application-enforced row-level security are non-negotiable.
- Workloads are transactional and customer-facing.
Move or mirror into Fabric when:
- Workloads are analytical (scans, aggregations, historical trends).
- Data from multiple sources needs to be blended for BI or ML.
- A governed semantic layer on OneLake (Direct Lake + Power BI) is needed.
- Long-term retention or cross-domain sharing via Purview is in scope.
Choose the integration pattern by latency:
- Near real-time ->Fabric Mirroring (Azure SQL, Cosmos DB, Snowflake, PostgreSQL)
- Streaming -> Eventstream / Real-Time Intelligence
- Minutes–hourly -> Dataflows Gen2 / Pipelines
- Data already in ADLS/S3/GCS 0 -> OneLake Shortcuts (virtualize, don't copy)
Key principles:
- Keep one copy of truth in OneLake, let Warehouse, Lakehouse, KQL, and Power BI read the same data.
- Never run analytics directly on production OLTP.
- Prefer Mirroring and Shortcuts over ETL wherever supported.
- Govern centrally through OneLake and Purview.
In short: operational databases run the business; Fabric analyzes it. The decision comes down to workload type, latency SLA, and integration method.
Thank you.
Srikanth Cheri
CST Team.Hi binitafulpagare
We would like to inquire whether have you got the chance to check the solutions provided above in to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.
Thank you.