---
title: "Microsoft Fabric JDBC Connectivity: A Readiness Guide"
canonical: "https://data-driven.com/blog/microsoft-fabric-jdbc-driver-ga/"
pubDate: "2026-04-01T00:00:00.000Z"
updatedDate: "2026-08-25T00:00:00.000Z"
description: "Check supported Fabric endpoints, authentication options, driver limits, and migration steps before moving JDBC workloads to production."
tags: [microsoft-fabric, jdbc, data-engineering]
categories: [microsoft-fabric]
---
Microsoft Fabric supports more than one JDBC route. The right driver depends on whether the client needs a Fabric Data Engineering Spark session or a T-SQL endpoint.
That distinction matters. The drivers use different URLs, authentication flows, execution engines, and support boundaries.
## Path 1: Fabric Data Engineering
Microsoft documents a distinct Microsoft JDBC Driver for Fabric Data Engineering. Version 1.0 uses Fabric's Livy APIs to create a Spark session and exposes a JDBC 4.2 interface.
Its connection URL begins with `jdbc:fabricspark://`. The client supplies a Fabric workspace and lakehouse identifier, plus a supported authentication flow. Microsoft currently provides JARs for documented Java runtime versions.
Use this route when the application needs to submit Spark SQL through Fabric Data Engineering. It is not a generic replacement for every JDBC client or engine.
## Path 2: Warehouse and SQL analytics endpoints
Fabric Warehouse and SQL analytics endpoints expose a T-SQL connection endpoint. Microsoft's Warehouse connection guide uses the Microsoft JDBC Driver for SQL Server, published as `mssql-jdbc`.
This path uses the warehouse server name and item name as the database or initial catalog. Microsoft Entra authentication and the supported Fabric T-SQL surface apply.
Use it when a Java tool needs to query a Warehouse or SQL analytics endpoint. Do not assume a Spark option, SQL Server feature, or authentication mode works until it appears in the relevant Fabric documentation.
## Choose by execution contract
| Requirement | Data Engineering driver | SQL Server JDBC driver |
| --- | --- | --- |
| Fabric target | Lakehouse through Data Engineering | Warehouse or SQL analytics endpoint |
| Execution engine | Spark through Livy | T-SQL endpoint |
| URL family | `jdbc:fabricspark://` | SQL Server JDBC connection string |
| Driver package | Fabric Data Engineering JDBC driver | `mssql-jdbc` |
| Main validation | Spark session and resource behaviour | T-SQL and endpoint compatibility |
The table is a routing guide, not a compatibility promise. Check the current Microsoft page for each path before selecting a driver version.
## Production readiness checks
### Client and runtime
Confirm the application's Java version, JDBC library behaviour, connection pooling, and statement patterns. Run the actual client rather than relying on a generic SQL console.
### Identity
Choose a documented Microsoft Entra flow that matches interactive or unattended use. Keep credentials out of connection strings and source control. Apply the least privilege needed for the target workspace and item.
### Query behaviour
Test transactions, metadata discovery, data types, parameter binding, timeouts, and large results. Spark SQL and the Fabric T-SQL surface have different semantics.
### Operations
Capture connection failures, throttling, Spark startup time, query duration, and capacity use. Define who owns incidents across the client, identity, network, and Fabric layers.
## Migrate one workload at a time
Inventory each JDBC consumer and assign it to a target engine. Build a compatibility test from its real statements, authentication mode, and concurrency. Move to production only when that path meets functional, security, performance, and recovery gates.
“JDBC supported” is only the start. A reliable migration names the Fabric item, driver, version, identity, and execution behaviour for every client.