> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Run Compute over a Databricks Delta table version
description: >-
  Freeze a Delta table version or a governed export, keep warehouse credentials
  out of the work request, and load accepted results back through your own
  storage governance.
route: /docs/compute/integrations/databricks-delta
page_id: docs-compute-integrations-databricks-delta
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Data engineers running Compute against a governed Delta table
voice: D
reader_question: How do I run Compute over a Delta table without weakening my own governance?
primary_action: Freeze a table version and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-databricks-delta-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## What this connects

Delta tables you already govern, in one direction. Lithi reads a table version you froze, and writes an accepted result bundle that you load back yourself.

The conformance level is `import_compatible`: Lithi reads released open table and file formats, and the named level comes with a published conformance matrix. That is not a Databricks API, and Lithi never signs in to your workspace.

## Bind an exact input

A Delta table names its own versions, so bind that identity rather than a path.

Materialize the rows at one table version into a location you govern, then pin the bytes you wrote:

```json
"input": {
  "adapter": "<your registered storage adapter>",
  "location": "<the export you just wrote>",
  "credential_ref": "<a registered credential reference>",
  "snapshot": {
    "version_id": "<the Delta table version you exported>",
    "content_sha256": "<the digest of those exact bytes>"
  },
  "format": "<a released format profile>",
  "item_id_field": "<the column that identifies a row>"
}
```

Keep the exported schema beside the version number. A later table version can add, drop or retype a column, and the digest is what makes that visible rather than silent. See [how to pin a snapshot that cannot change](/docs/compute/inputs/immutable-snapshots).

## Credentials

`credential_ref` carries a reference to a credential you registered, never a secret. Register it, test it, read it back, and revoke it when the work ends.

Your warehouse credentials stay in your workspace. A work request carries no personal access token, password or connection string, and none reaches a job, a receipt or a result file.

## Formats and limits

Name the profile in `input.format`. The released profile decides how nulls, decimals, timestamps and nested fields are read, not the writer that produced the export.

The maximum item count is stated on the workflow descriptor and repeated on your quote. Your own `limits` object carries `deadline` and `maximum_price`.

## Commit the output

Accepted rows land in `data/part-*`, with the namespaced columns `lithi_status`, `lithi_result`, `lithi_error_code`, `lithi_confidence`, `lithi_evidence`, `lithi_verification` and `lithi_usage` appended.

`result-manifest.json` is written last and is the only complete-bundle marker. Part files alone never mean the job finished.

Loading is a separate step that you run. Read the counts in the manifest, write a new table version from the accepted parts, then reconcile that version's row count against the manifest before anyone queries it.

## What is not supported

Lithi makes no wire, SDK or endpoint compatibility claim for any Databricks service. Reading an open file format is not the same thing.

These are outside the adapter:

- Running notebooks, jobs or SQL in your workspace.
- Writing into your catalog on your behalf, or any path around your own storage governance.
- Live or streaming tables as an input. Freeze a version first.
- Passing a warehouse credential through a work request.

If the export moved after you quoted, admission answers `REPLAN_REQUIRED`. Re-export at a current table version, pin the new digest, quote again, then approve again. Approval is always its own act.
