Azure Synapse Analytics

About Azure Synapse Analytics

Azure Synapse Analytics is Microsoft's managed analytics service for organizations that need enterprise data warehousing, lake querying, Apache Spark processing, and data integration in one Azure workspace. It combines Synapse SQL, serverless Apache Spark, pipelines, and Synapse Studio around data stored in Azure. Existing Synapse estates remain supported, but Microsoft now directs new data warehouse projects to evaluate Fabric Data Warehouse first and provides migration assistants for dedicated SQL pools, Spark pools, notebooks, and related workloads. Synapse is therefore best evaluated as an established Azure analytics platform with strong enterprise controls and a clear migration path to Fabric, not as a discontinued service.

What workloads does Azure Synapse Analytics handle?

Azure Synapse Analytics supports enterprise data warehousing, data lake exploration, large scale data preparation, ETL and ELT pipelines, and Apache Spark processing. A workspace brings SQL, Spark, pipelines, linked services, notebooks, monitoring, and security controls into one environment.

This is useful when a team needs several analytics engines around the same Azure data estate. Synapse can support business intelligence back ends, analytical data marts, data engineering, operational reporting pipelines, notebook driven processing, and large scale transformations. It is not an application transaction database. Workloads that need high frequency OLTP should normally use services such as Azure SQL Database or Azure Database for PostgreSQL instead.

How do serverless SQL and dedicated SQL pools differ?

Serverless SQL pool lets teams query files in Azure Storage without provisioning a dedicated warehouse. Microsoft bills it according to the amount of data processed by queries, so it is a practical fit for ad hoc analysis, lake exploration, and workloads with irregular demand. Current Microsoft documentation lists a maximum query duration of 30 minutes and a maximum result set size of 400 GB shared across concurrent queries. A serverless SQL pool supports up to 100 user databases, excluding databases synchronized from Apache Spark.

Dedicated SQL pool provisions data warehouse compute measured in Data Warehousing Units. It is intended for predictable warehouse workloads that need distributed tables, workload management, indexing, and controlled capacity. Dedicated compute can be scaled and paused. Compute billing stops when a pool is paused, while storage charges continue. Table design still matters because fact, dimension, and staging workloads can require different distribution choices such as hash, round robin, or replicated tables.

How does Apache Spark work in Synapse?

Synapse includes serverless Apache Spark pools for data engineering, notebook development, machine learning preparation, and distributed transformations. A Spark pool definition controls node size, node count, autoscale behavior, and idle timeout. Microsoft does not charge just for defining the pool. Charges begin when Spark compute is instantiated for a session or job.

Autoscale and automatic pause can reduce idle cost, but they do not remove the need for workload sizing. Large pools, long development sessions, custom libraries, and persistent notebook activity can materially increase spend. Teams should separate development and production sizing, test autoscale boundaries, and use idle shutdown where it fits the workload.

How do Synapse pipelines and data integration work?

Synapse pipelines use the same core integration technology as Azure Data Factory. Pipelines can move data, run copy activities, invoke notebooks, execute Spark jobs, call SQL scripts and stored procedures, and coordinate other Azure services. This lets analytics teams keep orchestration near the SQL and Spark assets they operate.

Pipeline cost is separate from SQL and Spark compute. Charges can include orchestration activity runs, integration runtime usage, data movement, and any external Azure service called by the workflow. Organizations that already operate Azure Data Factory should decide whether a second orchestration surface simplifies ownership or creates duplicated pipelines, monitoring, and deployment processes.

What is the current Microsoft guidance for Synapse and Fabric?

Microsoft still documents and supports Azure Synapse Analytics, but its current dedicated SQL documentation now tells customers who are new to data warehousing to start with Fabric Data Warehouse. Existing dedicated SQL pool workloads can migrate to Fabric to gain access to the broader Fabric analytics environment.

This does not mean an existing Synapse deployment must be replaced immediately. Synapse can remain appropriate when a team depends on established dedicated SQL designs, Synapse workspace networking, existing Spark jobs, or mature operational processes. The practical buying question in 2026 is whether the workload benefits enough from Fabric's SaaS style architecture and integrated workloads to justify migration effort.

How can a dedicated SQL pool move to Fabric?

Microsoft now provides an automated Fabric Migration Assistant for Azure Synapse dedicated SQL pools. The guided flow can connect directly to the source dedicated SQL pool or use uploaded source metadata such as a DACPAC or SQL files. It creates a Fabric Warehouse destination and assists with metadata migration.

Microsoft also documents manual migration methods for teams that need more control. Options include Fabric Data Factory copy patterns, partitioned copy for larger fact tables, SQL Database Projects, stored procedure based conversion, CETAS extraction to Azure Data Lake Storage, COPY based ingestion, and dbt for supported schema and code conversion. Microsoft notes that T-SQL differences still require assessment, so a migration should include schema validation, code testing, data reconciliation, performance testing, and cutover planning rather than assuming every object is portable without change.

How can Synapse Spark and notebooks move to Fabric?

Microsoft provides migration guidance and assistants for Synapse Spark pools and notebooks. Spark pools can be mapped to Fabric starter pools, workspace default pools, or custom pools depending on configuration needs. When several Synapse pools with different libraries or properties are moving into the same Fabric workspace, Microsoft recommends using separate custom environments where that better preserves the required configuration.

Synapse notebooks can move through the migration assistant, manual export and import using the IPYNB format, or API based automation. Teams still need to validate referenced notebooks, Spark versions, workspace libraries, linked services, data connections, mount points, and other dependencies after migration. A notebook file moving successfully does not prove the workload will run unchanged.

How does Azure Synapse Analytics pricing work?

Azure Synapse does not have one flat subscription price. Pricing was checked on September 6, 2026. Dedicated SQL pool uses provisioned DWU capacity plus separate storage. Serverless SQL is billed by data processed. Apache Spark is billed by vCore usage and runtime. Data integration has separate orchestration, data movement, and integration runtime meters.

Microsoft also lists a Synapse commit unit pre purchase model for eligible generally available Synapse services. The live Microsoft pricing page currently shows one year commit tiers with discounts that increase by commitment level. Buyers should model the actual region, service mix, query pattern, storage, network transfer, monitoring, and integration usage instead of using a single headline rate. Pause and resume for dedicated SQL, automatic pause for Spark, and efficient columnar file formats can materially affect spend.

What are the main security and governance considerations?

A Synapse workspace combines Azure resource permissions with Synapse specific roles. Microsoft documents roles for administration, SQL, Spark, artifact use, compute operation, credentials, and linked data management. Least privilege matters because broad workspace administrator access can expose SQL, Spark, pipelines, linked services, and credentials through one control plane.

Synapse also supports managed virtual networks, managed private endpoints, Microsoft Entra authentication, Azure Storage permissions, and workspace network controls. Security design should cover workspace access, storage access, network isolation, secrets, pipeline identities, and the people allowed to publish or execute analytical artifacts. Existing environments should also review Microsoft's current networking guidance before making long term assumptions about trusted service access patterns.

What limitations and tradeoffs should buyers evaluate?

Synapse brings several analytics engines together, but each engine still has its own performance model, operational limits, and billing behavior. Serverless SQL is convenient for lake queries but long or poorly filtered scans can become expensive, and Microsoft limits individual queries to 30 minutes. Dedicated SQL requires distribution and workload design. Spark requires pool sizing, session management, library governance, and engineering skills. Pipelines add another operational layer and may overlap with Azure Data Factory.

Migration to Fabric also has real work behind it. SQL syntax, notebooks, Spark libraries, pool configuration, data connections, security, and orchestration can require changes. Teams should assess compatibility before treating Fabric migration as a simple lift and shift.

Who is Azure Synapse Analytics best suited for?

Azure Synapse Analytics remains a strong fit for enterprises with established Azure analytics estates that need dedicated SQL warehousing, serverless lake querying, Spark, and orchestration under one workspace. It is especially relevant when teams already operate Synapse successfully and have invested in data models, pipelines, security controls, and operational processes that would be expensive to replace without a clear business benefit.

It can also fit organizations that need Azure specific networking and governance patterns around an existing analytics platform while they plan a gradual Fabric transition rather than a disruptive platform rewrite.

Who should choose something else?

Organizations starting a new Microsoft data warehouse project should compare Fabric Data Warehouse first because Microsoft's current guidance explicitly points new data warehouse customers there. Teams that mainly need Spark engineering should also compare Fabric Data Engineering and Azure Databricks. Small teams that only need dashboards over a modest SaaS data set may find a simpler warehouse or Fabric capacity easier to operate.

Application teams that need transactional relational storage should use an OLTP database instead of Synapse. Existing Synapse customers should not migrate solely because Fabric is newer, but they should have a documented reason for staying, understand their migration options, and avoid expanding Synapse by default when a Fabric architecture would better match new workloads.