Synapse Link for Cosmos DB lets you analyze data that is still living in Azure Cosmos DB without exporting it through scheduled jobs. You enable the feature on the Cosmos DB account and analytical store on the containers that should be queried. Synapse then reads a column-oriented analytical copy instead of hammering the transactional store. The learner point in 2026 is lifecycle context: Microsoft steers new projects to Fabric mirroring, while existing Synapse Link estates still need safe operation and migration planning.
Azure Synapse Link for Azure Cosmos DB, Cosmos DB Synapse Link, Cosmos DB analytical store link, Synapse Link analytical store, HTAP for Cosmos DB
Difficulty
advanced
CLI mappings
5
Last verified
2026-05-27T06:46:29Z
Microsoft Learn
Synapse Link for Cosmos DB is the legacy Azure integration that exposes Cosmos DB analytical store to Synapse for near-real-time analytics without custom ETL. Microsoft now directs new projects toward Cosmos DB Mirroring in Microsoft Fabric, so existing deployments need careful governance and migration planning.
Architecturally, Synapse Link sits between a Cosmos DB account, analytical store on selected containers, and a Synapse workspace using Spark or serverless SQL. Account flags, analytical TTL, schema representation, supported API, keys, private endpoints, and workspace access control the data path. In current planning, it should be treated as an existing-estate capability and migration subject, not a default new architecture. Technical reviews should capture every linked container, consumer, region, credential, and replacement path toward Fabric mirroring where appropriate.
Why it matters
Synapse Link for Cosmos DB matters because it may still carry important analytics even though it is no longer recommended for new projects. Existing dashboards, notebooks, fraud models, and operational reports can depend on analytical store and Synapse runtime behavior. If teams ignore the term, they risk breaking consumers during modernization or leaving sensitive operational data exposed through old workspace permissions. If they over-invest in it, they may deepen technical debt. The practical value is knowing how the existing bridge works, where it is enabled, what it costs, who queries it, and how to migrate without losing business-critical freshness. That clarity prevents rushed decisions during high-risk cutovers.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In Cosmos DB account and container settings, analytical storage flags and analytical TTL values show whether existing containers still feed Synapse Link workloads during migration reviews.
Signal 02
In Synapse Studio, linked services, Spark gestures, and serverless SQL scripts reveal which Cosmos DB containers are queried through analytical store during freshness investigations and migration testing.
Signal 03
In migration inventories, reports listing analytical-store containers, account keys, private endpoints, notebook consumers, and owners expose remaining Synapse Link dependencies during quarterly cleanup planning and owner review.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Inventory existing Synapse Link deployments before deciding what to retire, keep temporarily, or migrate to Fabric mirroring.
Keep current dashboards stable while validating a replacement zero-ETL architecture against the same operational data.
Identify containers with indefinite analytical TTL that create cost or privacy exposure without active consumers.
Separate transactional application health from analytical freshness issues during incidents in legacy Synapse estates.
Produce audit evidence showing who can query Cosmos DB analytical store from Synapse and through which workspace.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Logistics operator maps legacy Synapse Link before Fabric migration
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A logistics operator had an existing Synapse Link path from Cosmos DB vehicle telemetry to dispatch dashboards. New platform standards required a migration plan, but dispatch could not lose near-real-time visibility.
🎯Business/Technical Objectives
Inventory every linked container, report, and notebook before migration work began.
Keep dispatch dashboards fresh during severe-weather operations.
Reduce analytical retention where no active consumer remained.
Prove the replacement path matched current totals before cutover.
✅Solution Using Synapse Link for Cosmos DB
The cloud team used Azure CLI to export Cosmos DB analytical storage settings, container analytical TTL, Synapse linked services, and private endpoint evidence. Three telemetry containers were confirmed as business-critical, while two older pilot containers had no active consumers. Engineers built the replacement analytics path in parallel and compared route exception counts, temperature alerts, and vehicle-location freshness against the old Synapse Link output for four weeks. The existing Synapse path stayed read-only during validation, and any TTL changes required dispatch-owner approval.
📈Results & Business Impact
Two unused analytical containers were disabled, saving about $3,100 per month.
Critical dashboards stayed within a 10-minute freshness target through the migration test period.
Replacement queries matched old Synapse Link totals within the agreed 0.5 percent tolerance.
Cutover approval took one meeting because owners saw container, report, and metric evidence together.
💡Key Takeaway for Glossary Readers
For existing estates, Synapse Link knowledge is essential for safe migration, not just day-to-day analytics troubleshooting.
Case study 02
Game studio stabilizes fraud analytics while retiring old links
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An online game studio used Synapse Link for Cosmos DB to feed fraud models from player sessions and marketplace events. Security wanted the old workspace reviewed before a broader analytics modernization.
🎯Business/Technical Objectives
Keep fraud scoring data available during tournament season.
Find overexposed containers that analysts no longer needed.
Move credentials out of ad hoc notebook configuration.
Create a retirement sequence that avoided model drift surprises.
✅Solution Using Synapse Link for Cosmos DB
Engineers inventoried Cosmos DB accounts, analytical TTL values, Synapse notebooks, and serverless SQL views used by fraud analysts. They found one linked container that included support-chat metadata and removed it from the active analytical path after validating no model features used it. Account-key handling was moved into reviewed Synapse credentials, and private endpoint status was documented. The modernization team then compared old fraud-feature outputs with the replacement pipeline during tournament play, using CLI reports to show exactly which containers remained linked until final signoff.
📈Results & Business Impact
Fraud feature freshness stayed under 12 minutes during the tournament peak.
One sensitive support metadata container was removed from analyst access.
Model feature mismatches were caught two weeks before retirement instead of after cutover.
Security review time fell by 60 percent because linked containers and credentials were documented.
💡Key Takeaway for Glossary Readers
A legacy Synapse Link path can be stabilized and reduced before migration, which lowers both security risk and cutover anxiety.
Case study 03
Municipal services team separates citizen privacy from trend reporting
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A municipal services department used Cosmos DB for pothole, leak, and outage reports. A legacy Synapse Link dashboard helped council staff, but citizen contact details were visible to too many workspace users.
🎯Business/Technical Objectives
Preserve daily service-trend reporting while reducing exposure of resident PII.
Identify which containers still justified analytical retention.
Create evidence for privacy officers before modernization funding.
Retire old Synapse consumers only after replacement dashboards were validated.
✅Solution Using Synapse Link for Cosmos DB
The data team used CLI and Synapse artifact searches to map linked containers, SQL scripts, notebooks, and workspace roles. Analytical TTL was shortened for incident-detail containers, while a curated anonymized trend output was built for council dashboards. During the transition, the old Synapse Link path remained available only to a reduced operations group. Privacy officers reviewed fields, linked-service definitions, and private endpoint evidence before approving the replacement plan. Parallel dashboard runs compared borough counts, resolution times, and category trends until the new output met tolerance.
📈Results & Business Impact
Workspace users with access to raw linked reports fell from 42 to 9.
Incident-detail analytical retention dropped from indefinite to 45 days.
Council trend dashboards matched old totals within 1 percent for six consecutive reporting cycles.
The modernization business case included measured privacy reduction and a concrete retirement date.
💡Key Takeaway for Glossary Readers
Understanding Synapse Link helps public-sector teams protect residents while moving legacy analytical paths to safer patterns.
Why use Azure CLI for this?
With ten years of Azure operations in mind, CLI is the fastest way to turn a vague Synapse Link dependency into hard evidence. I use it to list Cosmos DB accounts, inspect analytical storage, verify container TTL, find linked services, and export workspace references before modernization. Portal pages are too slow when a migration team needs a complete dependency map. CLI also lets engineers prove which containers are still active, which ones hold sensitive data, and which workloads can be retired before moving to Fabric mirroring. That evidence keeps migration decisions grounded instead of political. It also exposes forgotten consumers before risky retirement changes.
CLI use cases
List Cosmos DB accounts and find where analytical storage is enabled across a subscription.
Show containers to verify analytical TTL and identify containers retaining analytical data indefinitely.
List Synapse linked services that point to Cosmos DB accounts during modernization assessment.
Export account, container, workspace, and private endpoint metadata for migration dependency mapping.
Compare development, test, and production links before retiring an old analytical path.
Before you run CLI
Confirm the tenant, subscription, resource group, Cosmos DB account, database, container, and Synapse workspace before collecting evidence.
Treat enablement or TTL updates as production changes because they can affect cost, retention, privacy, and downstream reports.
Check whether the command will expose keys or connection strings, and prefer redacted JSON output for shared evidence.
Ask whether the goal is stabilization, decommissioning, or migration to Fabric mirroring before changing configuration.
Coordinate with report owners before disabling analytical TTL or deleting linked services that may still feed dashboards.
What output tells you
Account properties show whether analytical storage is enabled and which schema representation was chosen for supported APIs.
Container analyticalStorageTtl tells you whether analytical data is disabled, time-limited, or retained indefinitely.
Synapse linked-service JSON shows whether the workspace still references the Cosmos DB account and how credentials are supplied.
Resource IDs, locations, and workspace names help map old analytical paths to migration owners and replacement targets.
Private endpoint and firewall-related output helps distinguish access failures from analytical-store freshness or query-design problems.
Mapped Azure CLI commands
Command bundle
az cosmosdb show --name <account-name> --resource-group <resource-group>
az synapse linked-service list --workspace-name <workspace-name>
az synapse linked-servicediscoverAnalytics
Architecture context
In architecture reviews, Synapse Link for Cosmos DB now belongs in an existing-estate assessment lane. The older architecture separated transactional Cosmos DB workloads from Synapse analytical queries through analytical store, which helped avoid custom ETL and transactional RU consumption. That pattern may still be working, but new zero-ETL designs should consider Cosmos DB Mirroring for Microsoft Fabric. A seasoned architect documents source containers, analytical TTL, regional needs, serverless SQL or Spark consumers, private networking, key handling, and report owners. Then the team decides what to keep temporarily, retire, or migrate. This avoids treating legacy integration as a permanent strategic foundation.
Security
Security risk remains high for existing Synapse Link deployments because analytical store can expose operational documents to a different audience than the application. Current reviews should ask whether workspace users can query every container in an account, whether keys are stored safely, whether private endpoints isolate analytical access, and whether sensitive fields should have been linked at all. Customer-managed key dependencies and Key Vault permissions also matter. The migration angle adds another risk: teams may copy old broad permissions into Fabric or other replacements unless they classify data and redesign access intentionally. Access reductions should happen before data is copied into replacements.
Cost
Cost impact includes analytical store storage, analytical operations, Synapse serverless SQL scans, Spark pool usage, and the engineering cost of maintaining legacy dependencies. Existing links can still be cheaper than brittle ETL, but unowned containers with indefinite analytical TTL are classic hidden spend. Modernization adds another cost dimension: dual-running Synapse Link and a replacement during validation is temporary but real. FinOps reviews should rank linked containers by query value, data growth, sensitivity, and migration readiness. Retire low-value links first, then move high-value consumers with measured before-and-after cost evidence. Budget owners should approve each planned month of dual-running migration expense.
Reliability
Reliability is about preserving dependent analytics while reducing legacy risk. Synapse Link can remove custom ETL failure points, but existing workloads still depend on analytical store sync, container configuration, API support, Synapse workspace access, credentials, and query runtime availability. Modernization can break dashboards if teams disable analytical TTL or linked services before mapping consumers. Operators should monitor freshness, query failures, and workspace reachability until migration is complete. The safe pattern is parallel validation: keep the existing Synapse Link path running, build the replacement, compare outputs, then retire only after consumers sign off. Consumer signoff should be tied to measured freshness and totals.
Performance
Performance value comes from analytical workloads reading analytical store instead of the transactional row store, so application RU/s is protected. Existing Synapse Link consumers may still rely on this isolation for dashboards or models. Performance problems usually come from broad serverless SQL scans, cold Spark sessions, poor document shape, cross-region access, or outdated assumptions about freshness. During migration, compare query latency, freshness, and scan cost against the replacement path rather than assuming newer is automatically faster. Keep representative performance tests before cutting over business-critical reports. Baseline tests should include old Synapse queries and replacement query paths under realistic load conditions.
Operations
Operations work starts with inventory. Teams should identify every Cosmos DB account with analytical storage enabled, every container with analytical TTL, every Synapse linked service, every SQL or Spark consumer, and every owner. They also need runbooks for freshness complaints, key rotation, private endpoint failures, and container-level retention changes. Because Microsoft points new projects away from Synapse Link, operations should add a migration backlog item to each remaining dependency. The backlog should name the business owner, replacement target, test evidence, cutover date, and rollback plan. A maintained register prevents surviving links from becoming invisible legacy infrastructure during modernization waves and audits quarterly.
Common mistakes
Starting a new project on Synapse Link for Cosmos DB instead of following current guidance toward Fabric mirroring.
Disabling analytical TTL before confirming which dashboards, notebooks, or models still depend on the linked container.
Assuming old Synapse workspace permissions are safe to copy into the replacement analytics platform.
Leaving indefinite analytical retention enabled after the only active report has been retired.
Troubleshooting a stale dashboard as an application outage when the issue is analytical sync, workspace access, or query path.