Azure Analytics Services (Synapse, Data Factory, Event Hubs, Stream Analytics)¶

Scope¶

The Azure analytics and data integration services that sit outside Microsoft Fabric, and Microsoft's current stated posture on each. Covers Azure Synapse Analytics (dedicated SQL pools and DWU sizing, serverless SQL pools and per-TB billing, Apache Spark pools), Azure Data Factory (integration runtimes, the self-hosted IR, Azure-SSIS IR, and the pricing meters), Azure Event Hubs (tiers, throughput units versus processing units, partitions, Capture, Kafka compatibility), Azure Stream Analytics (streaming units, windowing, delivery semantics), and Azure Synapse Link for Cosmos DB, Azure SQL, and Dataverse. Its central purpose is to state plainly where these services remain the right answer and where Microsoft Fabric supersedes them — including the cases where Fabric does not yet have an equivalent. For Fabric itself see providers/azure/fabric.md; for Azure Data Explorer see providers/azure/data-explorer.md; for the cost-sized pipeline patterns these services assemble into see patterns/data-pipeline.md.

Lifecycle status claims in this file were verified against Microsoft Learn on 2026-07-26. Retirement announcements frequently appear on Azure Updates or the Fabric blog before Microsoft Learn, so re-verify before making a commitment on the basis of an absent retirement notice.

Checklist¶

Lifecycle Posture: What Is Actually Retiring¶

[Critical] Is the Synapse lifecycle position stated accurately rather than from market rumour? Azure Synapse Analytics has no announced retirement or end-of-support date. Its Microsoft lifecycle entry reads "In Support"; the overview page, the FAQ, and the create-workspace quickstart carry no deprecation banner; and new workspaces remain creatable with no documented restriction. What Microsoft does is place Tip banners on dedicated SQL pool pages steering new users to Fabric. Any specific "Synapse retires on date X" claim should be traced to a first-party source before it is repeated in a decision document.
[Critical] Are the component-level retirements that have been announced tracked separately from the platform? Azure Synapse Data Explorer (Preview) was retired on 7 October 2025 — "after this date, workloads running on Synapse Data Explorer will be deleted, and the associated application data will be lost." The Synapse "allow trusted Microsoft services" firewall exception is documented for retirement on 1 August 2026; third-party reports of a postponement into 2027 could not be confirmed against Microsoft Learn and should be verified directly with Microsoft.
[Critical] Is Synapse Link for Azure Cosmos DB on a migration path? Microsoft's banner is unambiguous and appears on three separate pages: "Synapse Link for Cosmos DB is no longer supported for new projects. Don't use this feature." The stated replacement is Azure Cosmos DB Mirroring for Fabric. No retirement date is published, so existing deployments are not on a clock — but no new ones should be built.
[Recommended] Is the softer wording on the other Synapse Link variants distinguished from the Cosmos DB position? Synapse Link for Azure SQL and SQL Server 2022 remains GA with the guidance "Instead of Azure Synapse Link, use Fabric Mirroring" — a recommendation, not a prohibition. Synapse Link for Dataverse is explicitly not being retired: "we want to enable you to export data well into the future." What was retired in that family is the legacy Export to Data Lake, deprecated 1 November 2024 with decommissioning from 25 March 2025.
[Recommended] Is Azure Data Factory's position understood as "next generation exists" rather than "deprecated"? Microsoft documents that "Data Factory in Microsoft Fabric is the next generation of Azure Data Factory" and tips new users toward Fabric, but there is no ADF lifecycle retirement entry and no end-of-support date. The 2026 what's-new entries are migration tooling and connector maintenance rather than new platform capability. "No new features mode" is a fair summary but is not Microsoft's wording.
[Optional] Is Azure Stream Analytics correctly understood as still recommended rather than superseded? Microsoft's technology-choice guidance, revised in 2026, states plainly: "Azure Stream Analytics is the recommended service for stream analytics on Azure." Fabric is not named as an alternative on that page. The documented reasons to choose something else are UDFs in a language other than JavaScript or C#, and multicloud or on-premises portability.

Synapse Dedicated SQL Pool¶

[Critical] Is the pool sized in cDWU service levels against the documented concurrency ceilings rather than by intuition? Service levels are 16 discrete steps from DW100c to DW30000c, and concurrency is capped well below what a SQL Server background suggests: DW100c allows 4 concurrent queries, DW1000c allows 32, DW3000c allows 64, and DW6000c and above allow 128 — 128 is the absolute platform ceiling at any service level. Note that the documented "max concurrent queries" differs between the static and dynamic resource-class tables at the same service level, so always state which model a concurrency number applies to.
[Critical] Is the 60-distribution architecture and the distribution strategy decision understood before table design? Every query is divided into 60 parallel sub-queries, and compute nodes (1 to 60) each manage one or more of the 60 distributions. The three strategies are hash (up to 8 columns; requires DW_COMPATIBILITY_LEVEL = 50), round-robin (the default), and replicated (a full copy cached on each compute node). Once a distribution column or column set is chosen, it cannot be changed — the table must be recreated. Target skew below roughly 10%.
[Critical] Is pause/resume used, and is it understood that storage is still billed while paused? "Pausing compute causes the storage layer to detach from the compute nodes… data warehouse unit costs are zero during the pause… data storage isn't affected and your data stays intact." All running or queued operations are cancelled on pause, and both pause and scale invalidate the adaptive cache, so the first queries after resume are materially slower until the cache re-warms.
[Recommended] Are workload groups used rather than resource classes for new work? Microsoft states that "with the introduction of workload groups, the concept of concurrency slots no longer applies." Note the governance gap: "workload groups govern memory and CPU resources. Disk and network IO as well as tempdb are not governed" — a runaway tempdb consumer is not contained by workload isolation. tempdb is 399 GB per DW100c.
[Recommended] Is the distinction between a workspace-hosted dedicated SQL pool and a standalone "dedicated SQL pool (formerly SQL DW)" understood where migration or automation is involved? Microsoft states "the former SQL DW is in fact the same artifact" — the differences are control-plane rather than engine. Workspace pools do not use logical SQL servers; standalone ones do. Critically for automation, the PowerShell modules are not equivalent: standalone uses Az.Sql (New-AzSqlDatabase -Edition DataWarehouse) and workspace uses Az.Synapse (New-AzSynapseSqlPool), and "these two modules ARE NOT equal in all cases" — cross-subscription restore, for example, is Az.Sql only.
[Recommended] If migrating to Fabric Warehouse, is the T-SQL and type-conversion gap assessed with the Migration Assistant rather than estimated? Fabric Warehouse "doesn't support every Transact-SQL statement available in SQL Server": materialized views, triggers, synonyms, recursive queries, and manually created multi-column statistics are all unsupported. Required conversions include money → decimal(19,4), nvarchar → varchar, tinyint → smallint, and datetimeoffset is not supported at all. Indexes usually are not migrated, and distribution strategy has no Fabric equivalent. See providers/azure/fabric.md for the full Warehouse surface-area position.
[Optional] Is a pre-purchase plan (Synapse Commit Units) evaluated for steady-state pools, alongside the standard compute-plus-storage separation where DWU blocks and hours drive compute and TB stored drives storage?

Synapse Serverless SQL Pool¶

[Critical] Is the "data processed" billing unit understood as more than bytes read? Serverless SQL pool bills per TB processed, where processed means data read from storage plus intermediate results transferred between nodes uncompressed plus data written by CETAS, rounded up to the nearest MB per query with a 10 MB minimum per query. Microsoft's own worked example is the one to internalise: SELECT * over 1 TB of Parquet is 6 TB processed, because "it reads 1 TB and transfers 5 TB of uncompressed data."
[Critical] Are the cost-control thresholds configured before the pool is opened to analysts? sp_set_data_processed_limit sets daily, weekly, and monthly TB budgets simultaneously; consumption is visible in sys.dm_external_data_processed. Note the enforcement nuance: "In case any limit is exceeded during the query execution, query won't be terminated. When limit is exceeded, new query will be rejected." A single runaway query still completes and still bills.
[Critical] Is it understood that serverless SQL pool cannot store or load data at all? "Serverless SQL pool has no local storage, only metadata objects are stored in databases" — no tables, no triggers, no materialized views, no DML, and no DDL beyond views and security. INSERT, UPDATE, DELETE, MERGE, and CTAS are all unsupported; CETAS is the only write path and it writes files, not tables. It also has no RLS, no data masking, no result-set caching, and no workload management.
[Recommended] If planning to replace serverless SQL pool with Fabric, is it recognised that nothing in Fabric reproduces the TB budget cap? Fabric bills by Capacity Units, which is a structurally different model with different failure modes (throttling rather than query rejection at a spend threshold). The behavioural analogue for querying files in place is the Fabric SQL analytics endpoint, but Microsoft's own Tip banner on serverless pages points to Fabric Data Warehouse — the mapping is an inference, not Microsoft's stated equivalence. This is one of the clearest cases where Fabric does not yet have a like-for-like answer.

Synapse Spark Pools¶

[Critical] Is Spark pool billing understood as time-based regardless of utilisation? "Apache Spark Pool — you're charged per vCore hour and prorated by the minute," and "billing for Spark instances is prorated per minute, whether you are using them or not." Pool definitions are free; instances are not. Autoscale ramp time sits inside the billed window.
[Critical] Is auto-pause configured tightly? The default idle timeout is 15 minutes with a documented minimum of 5. Autoscale operates independently: minimum and maximum nodes up to 200, the minimum cannot be fewer than three, metrics are evaluated every 30 seconds, and "it can take 1 to 5 minutes for a scaling operation to complete."
[Critical] Are the specific reasons Microsoft documents for staying on Synapse Spark checked against the workload before planning a Fabric migration? Verbatim: "Use Azure Synapse Spark when you need GPU-accelerated pools, external Hive Metastore, or JDBC connections." Fabric additionally does not support .NET for Spark (C#), workspace-level library packages, or Spark job definition UI import/export. Any of these makes Fabric the wrong destination today.
[Recommended] Is the structural difference in the Fabric Spark model understood where migration is planned? "Azure Synapse: a Spark pool is a fixed compute resource… Fabric: a Spark pool is a configuration template, not a fixed backing compute resource," with sizing constrained by capacity vCores at 1 capacity unit = 2 Spark vCores and 3x burst. Fabric adds starter pools with 5–10 second start, a 1-node minimum, and a fixed non-configurable 2-minute autopause, and Microsoft states that in Fabric "you aren't charged for the time the clusters are idle" nor for cluster creation and deallocation — a genuine billing improvement over Synapse.
[Optional] Are node families chosen deliberately — Memory Optimized from Small (4 vCore / 32 GB) to XXLarge (64 / 432), plus GPU-accelerated and the XXXLarge isolated-compute option — recognising that a cluster is one head node plus a minimum of two workers?

Azure Data Factory and Integration Runtimes¶

[Critical] If moving to Fabric, has the self-hosted integration runtime replacement gap been assessed rather than assumed closed? Microsoft's migration guidance is "replace SHIRs with OPDGs and VNet IRs with Virtual Network Data Gateways," but the on-premises data gateway differs on points that matter in regulated environments: Private Link for control flow is supported by SHIR and not supported by OPDG; OPDG has no auto-update and no Azure Key Vault integration; and OPDG is Windows-only with no container image, where SHIR ships one. OPDG does support up to 10 HA nodes (SHIR supports 8), sharing across all supported services in the tenant, and recovery-key-based restore.
[Critical] For an SSIS estate, is it recognised that Azure-SSIS IR in ADF remains the only GA, VNet-injectable, on-premises-capable, custom-component-capable SSIS host? Fabric has gained an Invoke SSIS Package activity, but it is in preview and its documented limitations are precisely the enterprise lift-and-shift blockers: "OneLake only," "no on-premises data sources or destinations," "no private-network endpoints," "no custom or third-party components." Microsoft's own migration guide still routes SSIS through ADF: "execute SSIS packages using ADF pipelines and call them from Fabric." Microsoft's documentation is internally inconsistent here — the Fabric/ADF comparison page, revised later than the activity page, still lists SSIS as N/A in Fabric — so verify current status before planning.
[Critical] Is the ADF pricing model understood as multi-meter rather than a single rate? The meters are orchestration activity runs, Data Integration Unit (DIU) hours for copy on Azure IR, vCore hours for data flow execution and debugging, Azure-SSIS IR duration, pipeline and external pipeline activity execution, artifact operations, and an inactive pipeline monthly charge. Integration runtime charges are "prorated by the minute and rounded up," and with a managed VNet and no TTL configured, queue time is billable per activity.
[Recommended] Is the Fabric pricing structure compared honestly against ADF's rather than assumed cheaper? Fabric bills data movement at 1.5 CU hours, orchestration at 0.0056 CU hours per non-copy activity run, and SSIS at 1.35 CU hours per vCore; Dataflow Gen2 standard compute is 12 CU/s for the first 10 minutes then 1.5 CU/s, with a VNet data gateway billed at 4 CU on uptime. The structural difference is that Fabric has no counterpart to ADF's pipeline activity per-hour, external pipeline activity per-hour, or inactive-pipeline meters — which usually favours Fabric for estates with many idle pipelines.
[Recommended] Is the ownership inversion between ADF managed VNet and Fabric VNet data gateway understood in network design? "ADF Managed VNET: Microsoft owns and manages the network environment… Fabric VNET Data Gateway: you deploy the gateway inside your own Azure virtual network." Fabric's equivalent of ADF's managed VNet with auto-created private endpoints remains documented as "to be determined."
[Optional] Is it noted that Mapping Data Flows now exist in Fabric in public preview, running on the Synapse Spark runtime and supporting Assert, Alter row, Stringify, and Window transforms? This contradicts older Microsoft guidance listing those four as unsupported — the claim "Mapping Data Flows don't exist in Fabric" is out of date.

Azure Event Hubs¶

[Critical] Is the tier chosen against the retention requirement first, since no tier exceeds 90 days? Basic retains 1 day, Standard 7 days, Premium and Dedicated 90 days. Microsoft is explicit that "event hubs aren't intended as a permanent data store" — durable retention requires Event Hubs Capture writing to Blob or ADLS Gen2.
[Critical] Is the partition count decided correctly at creation, given it is effectively immutable? "For tiers other than the premium and dedicated tiers, you can't change the partition count for an event hub after its creation. For an event hub in a premium or dedicated tier, you can increase the partition count after its creation, but you can't decrease them." Increasing it breaks partition hashing for subsequently hashed messages, and Event Processor Host instances must all be restarted because they do not refresh metadata.
[Critical] Is throughput sized in the right unit for the tier, and is the asymmetric throttling behaviour known? A Standard throughput unit provides ingress up to 1 MB/s or 1,000 events/s, whichever comes first, and egress up to 2 MB/s or 4,096 events/s. Exceeding ingress throws ServiceBusy; egress is throttled silently with no exception — the second failure mode is the one that goes undiagnosed. Premium processing units are purchasable in 1, 2, 4, 6, 8, 10, 12, or 16 and are not throttle-limited in the same way; Dedicated capacity units provide roughly 100–200 MB/s ingress each with a 4-hour minimum billing period.
[Recommended] Is Capture configured where the data must outlive the retention window, with its constraints understood? Output format is Avro — "the Parquet format is supported only via Azure Stream Analytics integration." The time window defaults to 5 minutes (1–15) and the size window to 300 MB (10–500), with a first-wins policy. Capture "copies data directly from the internal Event Hubs storage, which bypasses throughput unit or processing unit egress quotas," and it is not retroactive.
[Recommended] Where Kafka compatibility is being relied on, are the tier and feature boundaries checked? The Kafka endpoint is "supported only in the standard, premium, and dedicated tiers," supports Apache Kafka 1.0 and later on port 9093 with SASL_SSL and OAUTHBEARER or PLAIN. Kafka Streams and Kafka Transactions are public preview and Premium/Dedicated only; compression is Premium/Dedicated only and gzip only; ksqlDB cannot be offered; and SAS tokens are not supported on the Kafka endpoint.
[Optional] Is the relationship to Fabric Eventstream understood as composition rather than replacement? "The Fabric eventstreams feature is associated with Azure Event Hubs… when you create an eventstream, an event hub namespace is automatically created for you," and the eventstream custom endpoint exposes Event Hub, AMQP, and Kafka protocol tabs producing a real Endpoint=sb://… connection string that works with the Event Hubs SDK. Positioning is an audience split, not succession — and MQTT is documented for Azure Event Hubs but not for Fabric Real-Time Intelligence.

Azure Stream Analytics¶

[Critical] Are new jobs sized in SU V2, given that SU V1 is documented as "to be deprecated"? The documented ratio is 6 SU V1 to 1 SU V2, where "1 SU V2 corresponds to one streaming node." Valid V2 values are 1/3, 2/3, 1, 2, 3 and upward to a maximum of 396. Note that the backend and REST encoding is not a clean multiple of the UI value — 2/3 SU V2 appears as 7, not 6.67. No SU V1 retirement date is published.
[Critical] Are delivery semantics stated precisely rather than as a single guarantee? Three separate facts: exactly-once processing is guaranteed unconditionally; delivery defaults to at-least-once because "output adapters don't write the output events transactionally," so duplicates are possible; and exactly-once delivery is achievable per sink. Cosmos DB is exactly-once by default via upsert; Event Hubs output is exactly-once by default; Azure SQL is conditional on a natural key with a unique constraint; Blob and ADLS Gen2 exactly-once is public preview and requires a specific write mode plus a path pattern containing both {date} and {time}. The canonical reference page's sink list is incomplete — check the individual sink pages.
[Recommended] Is the windowing model designed against the five documented window types — tumbling, hopping, sliding, session, and snapshot — with the constraint that the maximum window size in all cases is 7 days and every window must appear in a GROUP BY? All windows automatically align to the zeroth hour, which is a common source of unexpected bucket boundaries.
[Optional] Is it noted that the windowing reference page applies to both Azure Stream Analytics and Fabric Eventstream — a shared query surface? Fabric's Activator is a downstream no-code detection and action engine consuming Eventstream, not a stream processor, and no ASA-to-Eventstream migration guide exists on Microsoft Learn. The relationship is convergence rather than replacement.

Synapse Link and HTAP¶

[Critical] For Synapse Link for Cosmos DB, is the auto-sync latency and cost model understood where an existing deployment must be kept running? "Auto-sync latency is usually within 2 minutes. In cases of shared throughput database with a large number of containers… up to 5 minutes." Billing is three separate meters — analytical storage, analytical write operations, and analytical read operations — with no provisioned RUs. Microsoft's worked example: scanning 1 TB of analytical store is roughly 130,000 analytical read operations costing about $0.065, plus the serverless SQL scan cost.
[Critical] Is analytical TTL configured deliberately, given its destructive setting? ATTL = -1 means infinite retention irrespective of transactional TTL and is the portal default when the feature is toggled on; ATTL > TTTL yields analytical-only, read-only history; and ATTL = 0 turns Synapse Link off for the container and permanently deletes the analytical store. ATTL is container-level only. Synapse Link cannot be disabled at account level once enabled.
[Recommended] Is the access surface limitation known before designing around it? The analytical store is readable by Synapse Spark and serverless SQL pool only — "dedicated SQL pool is NOT supported" — with no SDK or REST access, no streaming from the analytical store, and no analytical-store backup. Supported APIs are NoSQL, MongoDB, and Gremlin (preview); Cassandra and Table are not supported.
[Recommended] Is it understood that Fabric Mirroring for Cosmos DB is a different mechanism, not a rebrand? "Mirroring does not use Azure Cosmos DB's analytical store or change feed as a change data capture source." Mirroring targets OneLake in open Delta format readable by every Fabric engine, requires continuous backup on the account (7- or 30-day; 7-day is free), supports NoSQL only, and is not available in sovereign clouds, for multi-write-region accounts, or with CMK on OneLake. Replication compute is free; Synapse Link's read and write operations are not.

Why This Matters¶

The most expensive error in this space is acting on a retirement that has not been announced. Azure Synapse Analytics is in support with no end date, yet a great deal of secondary commentary treats it as end-of-life. An organisation that rips out a working dedicated SQL pool estate on that basis pays for a migration it did not need, absorbs the Fabric Warehouse surface-area gaps — no materialized views, no triggers, no recursive queries, table-level locking, no cross-region connections — and discovers the datetimeoffset conversion cost after the plan is committed. The opposite error is equally real: building new Synapse workloads in 2026 means building on a platform receiving no new capability, with every Microsoft entry path pointing elsewhere. The defensible position is neither migration nor inertia; it is starting new work in Fabric while keeping running Synapse workloads that depend on capabilities Fabric has not yet built, and re-checking that dependency list each quarter.

Serverless SQL pool illustrates why "Fabric supersedes Synapse" is too coarse a statement. Its billing model — per TB processed, with a hard TB budget cap enforced by sp_set_data_processed_limit — has no Fabric equivalent. Fabric bills capacity units and manages overuse through smoothing and throttling, which is a different risk shape entirely: a runaway query in serverless costs money and then gets its successors rejected at a spend threshold; a runaway query in Fabric borrows future capacity and degrades everyone else's interactive experience hours later. For a team whose primary control requirement is a hard spend ceiling on ad-hoc lake querying, serverless SQL pool remains the better instrument, and no amount of platform strategy changes that.

Cost surprises in this stack come from unit definitions rather than from rates. Serverless SQL pool bills uncompressed inter-node transfer, so SELECT * over 1 TB of Parquet is 6 TB processed — a 6x multiplier that no one predicts from the storage footprint. Synapse Spark pools bill per minute whether or not work is running, so a pool with a 15-minute default auto-pause and interactive users costs far more than the job runtime suggests. ADF bills queue time as activity time when a managed VNet has no TTL configured. Event Hubs throttles egress silently with no exception raised, so the symptom presents as consumer lag rather than as an error. In each case the meter is documented and the surprise is entirely avoidable by reading the unit definition before sizing.

The integration runtime gap is the most common blocker when a regulated organisation tries to move ADF workloads to Fabric, and it is specific rather than general. The on-premises data gateway does not support Private Link for control flow, does not auto-update, and has no Key Vault integration — three things the self-hosted integration runtime does support, and three things that appear directly in security control matrices. Separately, Azure-SSIS IR remains the only generally available SSIS host that can be VNet-injected, reach on-premises sources, and run custom components; Fabric's preview equivalent explicitly cannot do any of those. An organisation with an SSIS estate and a private-networking mandate does not have a Fabric path for that workload today, and saying so early is more useful than discovering it in month four of a migration.

Common Decisions (ADR Triggers)¶

Start new analytics work in Synapse or in Fabric -- Fabric for greenfield, given Microsoft's entry-path steering, active investment, and the Power BI licensing economics vs Synapse only where a specific documented Fabric gap is load-bearing (GPU Spark pools, external Hive Metastore, JDBC from Spark, per-TB spend caps, cross-region connectivity, Azure-SSIS with on-premises reach)
Migrate an existing dedicated SQL pool now, later, or never -- migrate now using the Migration Assistant where the T-SQL surface fits and the concurrency ceiling is a constraint vs defer where materialized views, triggers, recursive queries, or cross-region connections are in use vs leave in place indefinitely, which remains defensible given no announced retirement date
Dedicated vs serverless SQL pool -- dedicated for predictable, high-concurrency, curated-warehouse workloads where provisioned cost is acceptable and pause/resume covers the idle window vs serverless for exploratory querying of files in the lake, where per-TB billing plus a hard TB budget cap is the desired cost shape and no data loading is required
Synapse Spark vs Fabric Spark -- Fabric for the capacity-based model, faster starter pools, and no idle charge vs Synapse where GPU-accelerated pools, an external Hive Metastore, JDBC connectivity, or .NET for Spark is required; Microsoft names these three explicitly as reasons to stay
ADF vs Fabric Data Factory -- Fabric for new integration work and where the inactive-pipeline and per-activity-hour meters dominate the bill vs ADF where SHIR capabilities are required (Private Link for control flow, auto-update, Key Vault integration, container deployment), where Azure-SSIS IR is hosting an SSIS estate, or where managed VNet with auto-created private endpoints is a requirement Fabric has not yet met
Self-hosted IR vs on-premises data gateway vs VNet data gateway -- SHIR for on-premises and network-restricted sources under ADF with Private Link and Key Vault requirements vs OPDG for the same sources under Fabric, accepting the three documented gaps vs VNet data gateway for Azure sources behind private endpoints with no infrastructure to manage
Event Hubs tier selection -- Basic only for non-durable dev scenarios vs Standard for most workloads with 7-day retention and Kafka support vs Premium for 90-day retention, dynamic partition scale-out, included Capture, and predictable multi-tenant isolation vs Dedicated for 20 MB publications and 100–200 MB/s per capacity unit, accepting the 4-hour minimum billing
Event Hubs partition count -- size for peak parallel consumers at creation, because Basic and Standard cannot change it afterward and Premium and Dedicated can only increase it, at the cost of breaking partition hashing and requiring every consumer to restart
Retention beyond the Event Hubs window -- Event Hubs Capture to Blob or ADLS Gen2 in Avro (bypasses egress quotas, not retroactive, first-wins windowing) vs a downstream stream processor writing to a lake table in the desired format (more control, more code, and the pipeline becomes a durability dependency)
Azure Stream Analytics vs Fabric Eventstream vs Kafka/Flink -- ASA where Microsoft's own recommendation, the 99.9% job-level SLA, and sub-100 ms latency fit and the query surface is SQL-shaped vs Fabric Eventstream where the destination is Fabric and Real-Time Intelligence is already in use vs Kafka and Flink where stateful processing, non-JavaScript/C# UDFs, or multicloud portability is required
Synapse Link for Cosmos DB vs Fabric Mirroring -- Fabric Mirroring for all new work, given Microsoft's "don't use this feature" banner on Synapse Link; keep Synapse Link running only for existing deployments and only where the Gremlin or MongoDB API is in use, since Mirroring supports NoSQL only. The prerequisite shift matters: Mirroring requires continuous backup on the Cosmos DB account
Analytical TTL configuration -- -1 for indefinite analytical retention independent of the operational store vs matching transactional TTL to mirror it vs a longer analytical TTL to retain read-only history the operational store has expired; never set 0 casually, as it permanently deletes the analytical store

Reference Architectures¶

What is Azure Synapse Analytics? -- workspace model and the four analytics runtimes
Azure Synapse Analytics lifecycle -- the authoritative support-status record
Modern Lifecycle Policy -- the notice terms that govern Azure service retirement, including the successor-product conditional
Azure Synapse Analytics FAQ -- standalone vs workspace pools and current feature positioning
Dedicated SQL pool architecture -- the 60-distribution model, control and compute nodes
Memory and concurrency limits -- the cDWU service level table with node counts, memory, and concurrency ceilings
What is a data warehouse unit (cDWU)? -- how DWU maps to compute and how billing works
Manage compute for dedicated SQL pool -- pause, resume, scale, and adaptive cache invalidation
Distributed table design guidance -- hash, round-robin, and replicated distribution selection and skew tolerance
Workload isolation -- workload groups, guaranteed concurrency, and what is not governed
Resource classes for workload management -- static and dynamic resource classes and their memory splits
Difference between the former SQL DW and a workspace pool -- the control-plane and PowerShell module differences
Serverless SQL pool overview -- pay-per-use model and what is and is not supported
Data processed by serverless SQL pool -- the billing unit, the uncompressed transfer multiplier, and cost control thresholds
Synapse SQL feature comparison -- per-statement dedicated vs serverless support matrix
Apache Spark pool configurations -- node sizes, families, and cluster shape
Automatically scale Apache Spark pools -- autoscale triggers, node bounds, and scaling latency
Plan and manage costs for Azure Synapse Analytics -- the per-service billing meters
Fabric and Azure Synapse Spark comparison -- the fixed-pool vs configuration-template model and when to stay on Synapse
Migrate a dedicated SQL pool to Fabric Warehouse -- migration planning and required conversions
Fabric Migration Assistant -- automated assessment and conversion tooling
Migrate Synapse Spark pools to Fabric -- pool mapping and configuration translation
Migrate Synapse Data Explorer to Fabric Eventhouse -- the retired-component migration path and its irreversibility
What is Azure Data Factory? -- pipelines, activities, datasets, and integration runtimes
Compare Fabric Data Factory and Azure Data Factory -- the feature-by-feature mapping including SHIR to OPDG
Access on-premises data from Fabric -- the on-premises data gateway path and its version requirements
Virtual network data gateway -- the customer-owned VNet gateway and supported workloads
Plan and manage costs for Azure Data Factory -- the full meter list including inactive pipelines
Deploy SSIS packages to Azure -- Azure-SSIS integration runtime provisioning
Event Hubs quotas and limits -- the per-tier limits table including retention and partition counts
Scaling with Event Hubs -- throughput units, processing units, capacity units, and auto-inflate
Dynamically add partitions -- which tiers allow partition changes and the hashing consequence
Event Hubs Capture overview -- windowing policy, Avro output, and egress-quota bypass
Event Hubs for Apache Kafka -- protocol compatibility, supported versions, and feature gaps
Choose a real-time analytics technology on Azure -- Microsoft's stated recommendation and the documented exceptions
Stream Analytics streaming unit consumption -- SU V1 vs SU V2 and the conversion table
Windowing functions -- the five window types, shared with Fabric Eventstream
Event delivery guarantees -- exactly-once processing versus at-least-once delivery, and per-sink behaviour
Azure Synapse Link for Azure Cosmos DB -- the "don't use this feature" banner and the HTAP mechanics
Azure Cosmos DB analytical store -- auto-sync latency, analytical TTL, and the three billing meters
Mirroring Azure Cosmos DB in Fabric -- the replacement mechanism, prerequisites, and limitations
Azure Synapse Link for SQL -- GA status and the softer Fabric Mirroring recommendation
Azure Synapse Link for Dataverse transition FAQ -- the explicit statement that Dataverse export is not being retired