Connecting Jedox to Databricks: the API route and the JDBC route

2026-08-05 · Jedox

Two working ways to get Databricks data into Jedox - a REST call against the SQL Statement Execution API, or the Databricks JDBC driver installed on the Jedox server so users can extract from SQL tables like any relational source. When to use which, with the setup details and the fine print.

More and more clients keep their governed data in Databricks and plan in Jedox, so "how do we connect the two" comes up regularly. There are two working routes. One goes over the Databricks REST API and needs nothing installed. The other uses the Databricks JDBC driver on the Jedox server, and once it is in place, Databricks behaves like any relational database in Integrator - users write SQL against tables instead of composing API calls. I use both, for different jobs; here is how each works and when I would pick which.

Option 1: the API route

Stefan Velickovic wrote a good beginner's walkthrough of this on Jedox 4 Beginners: Connecting Jedox to Databricks: A Beginner's Guide. The recipe in short, with credit to him:

1. In Databricks, find your table in the Catalog and generate a personal access token (User Settings, Generate New Token).
2. In Jedox Integrator, create a REST connection with method POST against your workspace's SQL Statement Execution API: https://<workspace>.cloud.databricks.com/api/2.0/sql/statements/, headers Authorization: Bearer <token> and Content-Type: application/json.
3. The request body carries the query and the warehouse:

{
  "statement": "SELECT * FROM catalog.schema.orders LIMIT 10",
  "warehouse_id": "<your warehouse id>"
}

4. Build an extract on that connection and map the result into your cubes and dimensions.

This works, needs no driver installation and no support ticket, and for small, fast pulls it is genuinely convenient.

What the beginner's guide does not cover, and what you should know before putting it in production - these details come from the Databricks documentation, not the article:

• The synchronous call has a ceiling. A single POST waits at most 50 seconds (wait_timeout); anything slower goes asynchronous, returns a statement id, and expects you to poll a status endpoint in a loop. A plain Integrator REST connection makes one call - it does not poll. So the simple pattern only fits queries that finish fast, and Databricks' own knowledge base documents pending statements failing when nobody polls them.
• Inline results cap at 25 MiB. Larger result sets require disposition=EXTERNAL_LINKS, which returns presigned cloud-storage URLs in chunks - again something a plain REST extract cannot follow. Practical consequence: slice big tables with LIMIT/filters, or accept the route is for modest volumes.
• The default JSON format returns every value as a string, so plan a transform for type casting.
• A personal access token is tied to a person. If that account is deactivated, the integration stops. For anything scheduled, use a service principal instead.

None of this is a criticism of the guide - it is a beginner's guide and does its job well. It is just the fine print you meet on the way to production.

Option 2: the JDBC route

The route I prefer for regular, larger or user-driven extracts: install the Databricks JDBC driver on the Jedox Integrator server, and Databricks becomes a normal relational source. Integrator's generic JDBC connection exists exactly for databases without a dedicated connector.

1. Get the driver onto the server.

• Jedox Cloud: you cannot drop files on the server yourself - driver installation goes through a support request via the Jedox Customer Portal. Open the ticket early, name the exact driver version and its download link, and budget some lead time. The same applies later when the driver needs updating.
• On-premises: copy the driver jar into the Integrator installation under .../tomcat/webapps/etlserver/WEB-INF/lib_external (Windows; on Linux the path starts .../tomcat-etl/...) and restart the Jedox Tomcat service (on-prem documentation). Skipping the restart is the usual reason the driver class is "not found".

2. Prepare the Databricks side. You need a SQL warehouse and three values from its Connection Details tab: server hostname, port (443) and the HTTP path (/sql/1.0/warehouses/<id>). If you can, use a serverless warehouse: it starts in a few seconds, while pro and classic warehouses cold-start in roughly four minutes - which is exactly how a scheduled morning load fails on its first attempt against a stopped warehouse.

3. Create the JDBC connection in Integrator. Driver class com.databricks.client.jdbc.Driver, and a URL like the one the workspace's Connection Details tab generates:

jdbc:databricks://<server-hostname>:443/default;transportMode=http;ssl=1;httpPath=/sql/1.0/warehouses/<id>;AuthMech=3;UID=token;PWD=<personal-access-token>

Two notes on that string. The transportMode=http;ssl=1 pair is a legacy-driver requirement that survives in the generated URLs - it does no harm, but the current minimal syntax is just host, port, httpPath and auth. And for production, swap the personal token for an OAuth service principal (AuthMech=11;Auth_Flow=1 with a client id and secret) - a PAT sits in the connection definition, expires, and belongs to a person.

4. Extract like from any database. From here it is a standard relational extract: users write SQL, preview rows, filter at the source, and load into cubes - no JSON parsing, no result-size gymnastics, no polling. One Unity Catalog detail: tables live in a three-level namespace, so write catalog.schema.table in queries, or add ConnCatalog=<catalog>;ConnSchema=<schema> to the connection URL so existing two-part queries resolve correctly.

Why I prefer the JDBC route

The difference shows up in who can use it. With the API route, every new pull means composing a request body and worrying about response size. With the JDBC route, the connection is set up once, and from then on any Integrator user who can write a SELECT statement can build extracts - the same skill they already use for every other relational source. Filters push down to Databricks, big tables come back without a 25 MiB ceiling, and the extract preview behaves like it does everywhere else. It is simply less machinery between the user and the data.

The trade-offs:

• The driver needs maintenance. Databricks ships driver updates every four to six weeks, and on Jedox Cloud every update is another support ticket. My advice: pin a known-good version, note it in your solution documentation, and update deliberately when you need a fix or feature - not on every release.
• It is not a certified connector. Jedox's documentation is explicit that third-party JDBC drivers are not tested with Jedox Integrator or Jedox Cloud, and Databricks is not on the supported-systems list. In practice it works well, but test in a sandbox before you promise it to a client.
• Timeouts on non-serverless warehouses. If the client insists on a pro or classic warehouse, the cold start can collide with the driver's default socket timeout; raising SocketTimeout in the URL is the usual mitigation.

Picking a route

• One-off or small, fast pulls, no patience for a support ticket: the API route. It works today with nothing installed - start with the Jedox 4 Beginners guide.
• Regular loads, larger tables, or extracts that ordinary Integrator users should build and maintain themselves: the JDBC route. One support ticket (or one jar drop on-prem), and Databricks becomes just another SQL source.

Both routes cover Databricks-to-Jedox. For the opposite direction - getting Jedox cube data out into a lakehouse - I have written up the full set of options, and the Python extraction guide applies here too.