> ## 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 BigQuery export
description: >-
  Bind a completed export or table snapshot identity, stage immutable files
  Compute can read, then load or commit results as a separate verified step you
  control.
route: /docs/compute/integrations/bigquery
page_id: docs-compute-integrations-bigquery
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Analytics engineers moving BigQuery data through a Compute workflow
voice: D
reader_question: How do I run Compute over BigQuery data and get the results back safely?
primary_action: Stage a completed export and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-bigquery-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

BigQuery tables you export yourself, in one direction. Lithi reads a finished export and writes an accepted result bundle back to result storage.

The conformance level is `import_compatible`, which means Lithi reads released open file formats under a published conformance matrix. Lithi does not run queries in your project and holds no BigQuery API compatibility claim.

## Bind an exact input

Wait for the export to finish before you bind anything. A half-written export directory is a moving source, and a partial read is the defect that is hardest to see later.

Bind the completed export by its own identity plus the digest of its bytes:

```json
"snapshot": {
  "version_id": "<the snapshot or export identity your project recorded>",
  "content_sha256": "<the digest of the exported bytes>"
}
```

Where the source is a table snapshot, use the snapshot's own identity. Where it is a scheduled export, use the export's completion identity. Either way the digest is what proves the run read those bytes. See [how to pin a snapshot that cannot change](/docs/compute/inputs/immutable-snapshots).

## Credentials

`input.credential_ref` names a credential you registered under sources. It is a reference, never a secret value, and you can test it, read it back and revoke it at any time.

Project credentials stay in your own tooling. Never place a service account key, a token or a signed URL in a work request, a support message or a shared example.

## Formats and limits

Name a released profile in `input.format`, and name the row identifier in `item_id_field`. Nested and repeated fields need the profile checked first, because a struct where the workflow declared a flat field is refused rather than flattened for you.

The maximum item count for a workflow is stated on its descriptor and repeated on your quote. Read [how a table should be prepared](/docs/compute/inputs/tabular-data) before a first large run.

## Commit the output

Accepted rows are written to `data/part-*` and `result-manifest.json` is written last, binding every file, count and schema in the bundle.

You then have two honest choices, and they are different acts:

1. Download the accepted parts and load them yourself, then compare your loaded row count against the manifest count.
2. Register a destination, so delivery is verified before it is committed. Delivery moves `PLANNED`, `AUTHORITY_READY`, `WRITING`, `WRITTEN_UNVERIFIED`, `VERIFIED`, `COMMITTED`, then `CUSTOMER_ACKNOWLEDGED`.

Nothing is a completed load until you have reconciled a count you read against a count the manifest states.

## What is not supported

Lithi is not a BigQuery client and claims no wire, SDK or endpoint compatibility with it.

Outside the adapter:

- Executing SQL, views or scheduled queries in your project.
- Reading a table directly while it is still receiving writes.
- Streaming buffers, or any export you have not confirmed complete.
- Any write into your project that bypasses your own access controls.

If a destination write conflicts, delivery reports `COMMIT_CONFLICT` with a next action rather than overwriting. Resolve the conflicting target, then retry the delivery without rerunning the job.