Skip to content
Close
SEARCH
Get a demo
Get a demo

Validated, authorized, and auditable write-back to Databricks

Business teams maintain mappings, reference data and corrections directly in Databricks Lakebase, while your platform team keeps the workspace, the schemas, the roles and the connections.
Get a demo
Get the deck
For the Databricks platform owner

Your lakehouse is where the business reads. It is rarely where the business writes.

Reporting and models moved onto Databricks. Maintenance mostly stayed behind: product groupings, cost center mappings, classifications and the reference tables behind them still live in spreadsheets and reach the lakehouse through a file and a request to your team. The platform pays back when people work inside it.

Keep business-maintained data inside Databricks

Every dataset maintained outside the lakehouse is a second version of the truth, a manual load in someone's notebook, and a reason a business team keeps its own copy. Bringing maintenance inside turns the lakehouse into the system of record people use.

Auditors ask where the number came from

ESG, the EU Taxonomy and financial controls all trace back to reference data someone maintains by hand. In a spreadsheet, the answer is a folder and a memory. On the platform, the value was validated at entry and it is on the record, with the person who entered it.

AI needs the data only your business teams know

Models and agents run on the mappings, classifications and parameters that live in people's heads today. Maintained in Lakebase, next to the lakehouse your models read, that context arrives validated and confirmed by a person. How NextTables powers AI.

How a business change reaches Databricks

Your business data stays in Databricks for the whole circuit, and the next change starts the same way.

  1. A business user edits

    They work in a grid they already know, on their own or inside a Power BI or Tableau dashboard, signed in with your identity provider.

  2. The entry is checked first

    Values are validated against your master data and your rules while the person is still in the field, so what reaches the platform is already correct.

  3. It is written into Lakebase

    It goes into the Lakebase schema your administrator scoped, through one login role, under the roles you defined.

  4. Dashboards have it immediately

    Databricks SQL, Power BI or Tableau read the maintained table at once, straight from the platform.

Embedded in your Power BI and Tableau dashboards

A NextTables application embeds in Power BI, Tableau or any tool that supports web objects, in a dedicated embedded mode that shows the grid alone. URL parameters carry the dashboard's context, so a user looking at one product group's report edits that group's rows, and only those.

Row-level rules can read the same access lists you keep for your BI reports, so the person who may see a row in the dashboard is the person who may maintain it.

The NextTables grid with a mapping table maintained by a business team

What the grid, the value help and the forms look like for the people who use them: Built for business teams.

What platform owners keep and business teams gain

A maintenance layer only survives if it works for the team that runs the lakehouse and the team that owns the data. Speed and control come from one mechanism here: the boundary is enforced by software rather than by a queue.

Platform owners keep

  • The boundary: the Lakebase database, the schema and the login role are yours. You decide which connection is available in which folder.
  • One storage location: business data lives in Databricks and only there. NextTables holds configuration metadata: applications, rules, roles, connection parameters.
  • The access model: roles are scoped to folders, and row-level rules can read the control tables you already maintain on the platform.
  • A clean exit: switch the connection off and the schema, the tables and the data are exactly as they were.

Business teams gain

  • Their own pace: a correction takes a minute instead of a request, a file and a pipeline run.
  • The right value, first time: search against your master data by text, so a person finds the product group by its name rather than its code. The master data can live in this platform or in another one NextTables is connected to.
  • Their data where the report is: the same grid runs standalone or inside the Power BI or Tableau dashboard they came from, filtered by its context.
  • Confidence: invalid values stop at the field, so the person entering the data finds the problem instead of the person consuming it.
For owners and architects

How NextTables connects to your Databricks workspace

NextTables stands outside your workspace and reaches it through Databricks Lakebase, the managed Postgres inside the lakehouse built for low-latency data applications. Writes go through one login role per schema; lookups stay read only. Your dashboards keep reading the platform exactly as they do today.
Architecture: dashboards on the lakehouse read the maintained tables; NextTables, outside the workspace, writes through one login role per Lakebase schema and reads master data and control tables read only

The questions an architecture board asks

Where does our business data live? Your business data stays in Databricks, and only there. NextTables keeps configuration metadata such as applications, validation rules, roles and connection parameters, and holds the data only while it is on its way into the platform.
How does a write reach the platform? Through Databricks Lakebase, using a native Postgres login role your administrator creates with read and write on one schema. The role reaches that schema alone, so the write surface is exactly as large as the job.
What is read, and how? Master data for value help and the control tables behind row-level rules are read through the same connection, read only. Existing tables can be connected read only and used as master data or as the basis for row-level rules.Master data can also come from another connected platform: one application validates against SAP Business Data Cloud and writes to Databricks, or the other way round.
What changes for reporting? Reporting stays as it is. Databricks SQL, Power BI or Tableau read the maintained tables the way they read every other table, one direction, and a maintained value is available at once.
How does this sit with Unity Catalog? Unity Catalog keeps governing your lakehouse. NextTables adds the maintenance layer on Lakebase and reaches only what the login role you grant may reach. Who may maintain which table inside that schema is decided by NextTables' folders, roles and row-level rules: Governed.
What does our platform's log show for a change? The login role, because that is what a database connection is. The person behind each change is recorded in NextTables' audit log against their signed-in identity, stored on the platform. A full audit trail inside the product is on the roadmap.

Which of these landscapes is yours?

NextTables fits the ownership model you already run on Databricks. Which schemas get a login role is the whole design decision, and these three are the shapes it usually takes.

Central data platform team

One Lakebase database, one schema and one folder per domain: the platform team keeps the workspace and creates one login role per schema. Each business group maintains its own tables in its own folder, through its own role.

Data product teams own their domain

One schema, one role and one folder per team: the team that owns an area creates its tables in its own schema, maintains them and joins them to its models.

Access lists maintained like any other table

A security schema with its own role: the control tables behind your row-level rules for Power BI or Tableau live in one schema, and the domains that own them maintain them in NextTables, validated at entry and on the record.

The setup behind each shape, click by click: creating the database connection and scoping a connection to folders in our knowledge base.

For the platform team that will run it

What your Databricks administrator does, once per schema

The whole setup stays inside Databricks and NextTables. The shape of the ask is here; the click-by-click walkthrough lives in the knowledge base.

  1. Create the Lakebase database

    Or use the one you have. Lakebase is Databricks' managed Postgres for real-time data applications, and the recommended target for maintenance.

  2. Enable Postgres login and create a role

    Turn on native Postgres role login, then create one login role with read and write on the single schema NextTables will use.

  3. Allow one IP

    The NextTables IP is shown at the top of the connection sheet. Add it to your network or platform allowlist once.

  4. Hand over the values

    Instance name, host, port, schema, username and password go into the connection, mapped to the folders that may use it. NextTables tests the connection before it is saved.

Step by step, including a dedicated role per connection and how to rotate a password: the Databricks integration guide in our knowledge base. Who may then maintain what is decided by folders, connection scoping, roles and row-level rules: Governed.

What you run, and what we run

The Databricks-specific questions an architecture board asks once the architecture is agreed, including the parts that are still on their way. Identity, support, security and residency are the same on every platform: Governed.
ConcernYour sideOur side
ConnectivityOne allowlist entry for the NextTables IP, and one Postgres login role per schema with native login enabled. Both are changes your team already knows how to make.We show the IP address in the connection sheet and test the connection before it is saved. Rotating the password means replacing one value in one field.
Authentication to LakebaseUsername and password on a login role scoped to one schema, least privilege.Native Postgres login is the supported method for the Lakebase connection today.
EnvironmentsOne folder per environment, development, test and production, with each environment's connection scoped to its own folder.Available today, and the recommended structure from the first day rather than a later migration.
PromotionYou decide what is ready to move and who may move it.Export a folder or a table with everything it depends on and import it into another folder or another tenant. Coming Soon
Concurrent editsToday, when two people edit the same row, the last write wins. Plan for that before rollout.Concurrency checks that warn a second editor before they overwrite are on the way. Scoped folders and row-level rules keep most teams in their own rows in the first place. Coming Soon
When you stop using NextTablesYour schema, tables and data are in Databricks throughout, so they stay.Your configuration travels with the same export used for promotion, so the application definitions leave with you too. Coming Soon

Where NextTables fits, and where something else fits better

A maintenance layer is easy to oversell. These are its edges, so you can place it against what you already run on Databricks.

A good fit for

  • Reference and mapping tables that business teams own and change often.
  • Corrections to data already on the platform, made by the people accountable for it.
  • Collections gathered from many contributors, for example ESG figures from subsidiaries.
  • Row-level access lists for Power BI or Tableau, maintained by the domains they apply to.
  • Business rule and parameter tables that pipelines, models and agents read.
  • The context data that AI and analytics depend on, still waiting for an owner end to end.

Better served by something else

  • Replacing an active master data management program. Where one already covers a domain, this sits outside it.
  • Moving or transforming data at volume. Your pipelines and Delta Live Tables keep that job.
  • Analysis and visualization. Reporting stays in Databricks SQL, Power BI or Tableau, reading what is maintained here.
  • High-frequency transactional writes from an operational application.

Frequently asked questions

1. How long does it take to get a first application live?

Hours to days once the connection exists. Setup is configuration rather than development, which is also why a trial against a sandbox schema is a realistic way to evaluate it.
2. Do our business users need a Databricks account?

They sign in to NextTables through your identity provider. The platform connection runs on one login role per schema, so maintenance-only users stay outside your workspace's user management and licensing.
3. Which platforms are supported today?

SAP Business Data Cloud (Datasphere), Databricks and PostgreSQL are generally available. Snowflake and Microsoft Fabric are on the roadmap.
4. Can one application maintain data across more than one platform?

Yes. An application can validate against master data in SAP Business Data Cloud and write to Databricks, with validation, authorization and traceability applied across the boundary.
5. How is NextTables licensed?

As a subscription for NextTables Cloud, sized by users and tables. The details are on the pricing page.
6. What support and release rhythm do we get?

An enterprise support model with one named path for your team, and a monthly release cycle, 30-plus releases and counting, so changes arrive on a predictable rhythm.
7. What happens to our data if we stop using NextTables?

It stays where it has been the whole time: in Databricks. Switch off the connection and the schema, the tables and every row remain as they are.

Bring your own lakehouse

Half an hour against your schemas, your roles and the ownership model you already run. Or take the deck to your architecture board first.

Get a demo
Get the deck