Connect Java tools to Fabric through a supported JDBC path

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.