SQL Strategy

Hi binitafulpagare 

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:

1. Keep one copy of truth in OneLake, let Warehouse, Lakehouse, KQL, and Power BI read the same data.
2. Never run analytics directly on production OLTP.
3. Prefer Mirroring and Shortcuts over ETL wherever supported.
4. 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.