Database guides
Azure Synapse Analytics
Synapse’s dedicated SQL pool is an MPP warehouse reached over TDS. AddisDB connects with its SQL Server driver and opens the Big Data Console.
Azure Synapse Analytics is Microsoft’s analytics platform; this entry connects to its dedicated SQL pool, the massively-parallel warehouse that grew out of Azure SQL Data Warehouse. It speaks TDS, so AddisDB connects with its SQL Server driver on port 1433.
Who it is for
A dedicated SQL pool suits large-scale reporting where the data volume has outgrown a single SQL Server and the workload is scans and aggregations rather than point lookups. Compute is provisioned in data warehouse units and can be paused, which is the main lever on cost.
It is important not to think of it as SQL Server with more hardware. A control node distributes work across compute nodes, and that architecture removes a large slice of T-SQL: no cross-database queries, restricted DDL, and a distribution clause required on every table. Statements that work on Azure SQL Database are routinely rejected here.
Set up the pool
- In the Azure portal open your Synapse workspace and copy the dedicated SQL endpoint — it looks like myworkspace.sql.azuresynapse.net.
- The port is 1433.
- Add your client IP to the workspace firewall rules.
- Make sure the pool is resumed. A paused pool refuses connections, and that refusal reads like a network failure.
- Note the pool name — that is what goes in the database field — and the SQL admin login.
Connect from AddisDB
- New Connection → Azure Synapse Analytics. Port prefills to 1433.
- Enter the endpoint as the host and the pool name as the database.
- Enter the SQL admin login and password.
- Set SSL mode to require — Synapse enforces encryption.
- Test, then Save.
What AddisDB gives you
The Big Data Console, since Synapse is catalogued as a warehouse engine, plus queries, the results grid, exports and saved queries. The schema tree reads the standard catalog views and loads normally.
The Live Monitor reports unsupported, and that is the honest answer rather than a gap. A dedicated pool routes work through its control node and reports it in the sys.dm_pdw_* views, not the sys.dm_exec_* ones the monitor reads. Query sys.dm_pdw_exec_requests directly to see what is running.
The structured create and alter table builders are hidden too. Every Synapse table needs a WITH (DISTRIBUTION = …) clause, so generated stock T-SQL would be rejected — write the DDL in the editor, where the distribution and index choices are yours to make.