Close the loop on the lakehouse
Read from Databricks, and write plan data back
Pull tables, views and query results into Nexadata, shape them for planning, and write forecasts, allocations and plan versions back to Databricks tables, run by the finance team rather than a data engineering queue.
At a glance
Two-way connectorOut of Databricks
- Tables and views in an OpenSharing share
- Your own SQL statement on a SQL warehouse
Back into Databricks
- Append
- Upsert on a business key
- Create the table on first run
Authentication
Service principal, user sign-in, or an OpenSharing profile.
- SOC 2 Type II
- Zero data retention
- SSO / SAML / RBAC
- Cloud-agnostic
The platform processes your data. An LLM never touches it.
The connector
What the Databricks connector does
Plan data belongs in the lakehouse too
A lakehouse records what happened. A planning system holds what the business intends: forecasts, allocations and plan versions the model calculates, plus the assumptions planners enter by hand. That data exists nowhere else. Writing it back puts plan next to the actuals it is measured against, governed the same way and ready for every report, model and AI workload that already reads from Databricks.
Two ways in, depending on what your admin will approve
Read the tables and views your admin has placed in an OpenSharing share, the narrowest access there is to approve, since Nexadata can read only what is in the share. Or run your own SQL statement on a SQL warehouse you choose, so you filter, join and aggregate inside Databricks before anything moves.
Write back with Append or Upsert
Append adds every row on each run. Upsert updates the rows that match a business key you choose and inserts the rest, so a plan version restated each cycle updates in place rather than piling up duplicates. Nexadata can create the table on the first run and add new columns as your output evolves.
Totals that tie to the cent, and rows you can trace
Every column is written at the type defined in the output rather than one Databricks guesses from a file, so money lands as a decimal. Every row is stamped with the ID of the Workflow run that wrote it, and rerunning a failed write does not create duplicates.
Access your admin can review and revoke
Connect as a Databricks service principal, which can do only what your admin grants it, or sign in as a named Databricks user so every action is recorded under your name. Secrets, tokens and profiles are encrypted and stored server-side.
Sources
Connect what feeds it
Databricks is rarely the only system in a plan. Join it to whatever else the answer needs: if a system has an OpenAPI or OData spec, the Connector Copilot reads it and builds a working connection, with no prebuilt connector to wait on.
How it works
From source system to Databricks
Connect, transform, map, review. Each step is guided by a no-code copilot, and you approve the plan before anything runs.
- 01
Connect
Create a service principal connection for SQL reads and write-back, or an OpenSharing profile for a read-only share. One service principal connection covers both directions.
- 02
Transform
Push filtering and aggregation into the SQL statement, then join, reshape and restate the result in Nexadata by describing it to the Transform Copilot.
- 03
Map
Line lakehouse codes up with the dimension members your planning model uses on the way in, and map plan output back to the keys your Databricks tables expect on the way out.
- 04
Review
Approve the plan before it runs, and keep the record of who changed a mapping group, what changed, how and when.
Use cases
What people run through it
Land plan data back in the lakehouse
Write forecasts, allocations and plan versions to a Databricks table on a schedule, upserting on a business key so each cycle's restatement replaces the last.
Try the round tripFeed planning from curated tables
Read the actuals your data team already curates in Databricks into the model your plan runs on, without a second copy of the logic in a spreadsheet.
See the use caseLet the warehouse do the heavy lifting
Filter, join and aggregate in a SQL statement on your own warehouse, so only the rows the plan needs leave Databricks.
Read the guidePartnership
A Databricks technology partner
Nexadata is a registered Databricks technology partner, and the connector is built on Databricks' own REST APIs and OpenSharing.
See all partnersSet it up
Step-by-step documentation
Every screen, in order, with screenshots.
Setting up a Databricks connection
Choose an authentication type and the access your admin grants.
Read the guideUsing a Databricks connection
Read from a share or a SQL statement, then write outputs back.
Read the guideRound trip between Databricks and Nexadata
Read a fact table, write it back, and confirm the totals tie.
Read the guideTroubleshooting the Databricks connector
Connection, permission, dataset and write-back errors.
Read the guideQuestions
Databricks integration FAQ
- Can Nexadata write data back to Databricks?
- Yes. Any Workflow output can be written to a Databricks table with Append, which adds every row, or Upsert, which updates rows matching a business key and inserts the rest. Nexadata can create the table on the first run and add new columns as the output changes.
- How does Nexadata read from Databricks?
- Two ways. Read the tables and views in an OpenSharing share, or run your own SQL statement on a SQL warehouse you choose, so filtering and aggregation happen in Databricks before the data moves.
- How does Nexadata authenticate to Databricks?
- With a service principal, the recommended choice for SQL reads and write-back; by signing in as a named Databricks user, so Nexadata acts with your privileges; or with an OpenSharing profile, which reads a share and nothing else.
- Does Nexadata need access to my whole workspace?
- No. A share exposes only what your admin places in it, and a service principal can do only what it is granted. A common setup grants read-only access to the source schema and write access to a separate schema for results.
- Will rerunning a Workflow create duplicate rows?
- Not with Upsert, which updates the rows that match the business key. Rerunning a failed or partly completed write does not duplicate rows either, because Databricks skips files it has already loaded.
More integrations
Other ways to connect
Pigment
Read from and write to Pigment blocks, views and lists, with column validation on every writeback.
ExploreAnaplan
Reach past your models into Anaplan's own tenant data, and load results back through the actions your model already runs.
ExploreSalesforce
Pull via SOQL or saved reports, tune extract mode for volume, and write back with insert, update, upsert or delete.
ExploreHubSpot
Read any standard or custom object with its associations, and write results back with upsert, create or update.
ExploreConnector Copilot
Load a spec, authenticate, describe the data you want, and get a typed dataset. Over 20,000 public APIs are documented in OpenAPI.
ExplorePDF documents
Detect and curate the tables inside a document, then reuse that configuration on every later file in the same layout.
ExploreSpreadsheets
Point at the sheet and the cell where the real data starts, and load a clean typed table out of a messy workbook.
ExploreSee the round trip on your own lakehouse
Read a table from Databricks, run it through Nexadata, and write plan data back, with totals that tie to the cent.