| name | materialize-databricks-create |
| description | Create a Databricks materialization to stream Estuary collections into Databricks tables via Unity Catalog. Use when setting up Databricks as a destination for captured data. Use when user says "send to Databricks", "materialize to Databricks", "Databricks destination", or "load into Databricks". |
Create Databricks Materialization
Create a Databricks materialization using flowctl to stream data from Estuary collections into Databricks Unity Catalog tables.
Applies to: materialize-databricks
Step 0: Load Connector Documentation
Before proceeding, fetch the official connector docs for prerequisites, config reference, and setup instructions.
Load the docs page:
https://docs.estuary.dev/reference/Connectors/materialization-connectors/databricks/
Use WebFetch to load this page. It covers:
- Prerequisites (Unity Catalog, SQL Warehouse, credentials)
- Full config property reference
- Authentication setup (PAT or OAuth2 M2M)
- Staging via Unity Catalog Volumes
Search Kapa for tribal knowledge (if the Estuary MCP is configured):
Search kapa ai knowledge sources for "materialize databricks common issues"
If Kapa MCP is not configured, the user can set it up: https://docs.estuary.dev/features/mcp-integration/
This skill provides the flowctl workflow and troubleshooting that docs don't cover.
Step 1: Gather Requirements
Before writing any YAML, ask the user:
- Workspace URL? — Databricks workspace hostname (e.g.,
dbc-abc123.cloud.databricks.com)
- SQL Warehouse HTTP path? — Found in SQL Warehouse > Connection details
- Catalog and schema? — Unity Catalog name and target schema
- Authentication method? — Personal Access Token (PAT) or OAuth2 Machine-to-Machine (M2M)
- Non-default data plane? — Most users use the default. Ask if they need a non-default data plane.
- Source collections? — Which Estuary collections to materialize
- Hard deletes? — Off by default. Without it, deleted rows stay in Databricks marked with
_meta/op: 'd'. Enable to physically remove them.
- Delta updates? — Off by default. Switches from one-row-per-key (standard merge) to append-only. Use for event logs or history tables.
- Sync schedule? — Controls how often batches are written to Databricks (default: 30 minutes,
0s for real-time). Affects latency and compute cost.
Step 2: Find the Correct Connector Version
Always use the latest numbered version tag. Query the connector registry:
flowctl raw get --table connector_tags \
--query 'documentation_url=eq.https://go.estuary.dev/materialize-databricks' \
--query 'select=image_tag,documentation_url' \
--output yaml
Use the returned image_tag — never hardcode a version.
Step 3: Help User Complete Prerequisites
Walk the user through prerequisites from the docs loaded in Step 0:
- Unity Catalog enabled — Required for staging data via Volumes
- SQL Warehouse running — Must be active during publish and ongoing operation
- Schema exists — Create the target schema if it doesn't exist
- Credentials ready — PAT token or OAuth2 M2M client ID/secret
Staging: The connector automatically creates a Unity Catalog Volume (flow_staging) for staging — no user setup needed for storage.
Refer to the docs page for exact setup steps.
Step 4: Create the Spec File
Build flow.yaml using the config reference from the docs.
With Personal Access Token (PAT):
materializations:
<TENANT>/<PATH>/materialize-databricks:
endpoint:
connector:
image: ghcr.io/estuary/materialize-databricks:<VERSION>
config:
address: "<WORKSPACE>.cloud.databricks.com"
http_path: "/sql/1.0/warehouses/<WAREHOUSE-ID>"
catalog_name: "<CATALOG>"
schema_name: "<SCHEMA>"
credentials:
auth_type: "PAT"
personal_access_token: "<TOKEN>"
bindings:
- source: <TENANT>/<collection-path>
resource:
table: "<TABLE_NAME>"
With OAuth2 Machine-to-Machine (M2M):
materializations:
<TENANT>/<PATH>/materialize-databricks:
endpoint:
connector:
image: ghcr.io/estuary/materialize-databricks:<VERSION>
config:
address: "<WORKSPACE>.cloud.databricks.com"
http_path: "/sql/1.0/warehouses/<WAREHOUSE-ID>"
catalog_name: "<CATALOG>"
schema_name: "<SCHEMA>"
credentials:
auth_type: "OAuth2 M2M"
client_id: "<CLIENT-ID>"
client_secret: "<CLIENT-SECRET>"
bindings:
- source: <TENANT>/<collection-path>
resource:
table: "<TABLE_NAME>"
Important: The connector is single-threaded — one failing binding blocks all bindings in the materialization. Group critical tables together and isolate experimental ones.
Step 5: Publish
flowctl catalog publish --source flow.yaml --auto-approve
Step 6: Verify
flowctl catalog status <TENANT>/<PATH>/materialize-databricks
flowctl logs --task <TENANT>/<PATH>/materialize-databricks --since 5m | jq -c '{ts, message}'
Status progression:
PENDING — Normal for ~30 seconds during shard assignment
BACKFILLING — Initial data sync from collections
OK — Running normally with real-time updates
Troubleshooting
"Field selection validation failed"
Cause: Usually a UI state issue (stale cache) or schema evolution conflict (required field no longer exists in collection)
Fix:
- Try a browser cache clear and reload
- Click the "Refresh" button in the Field Selection section
- Check if any required fields were pruned from the collection's inferred schema (complexity limit of 1000 fields)
- If a required field disappeared, either un-require it or re-add it to the collection schema
DELTA_UNSUPPORTED_DROP_COLUMN
Cause: Connector tried to drop a column but the table's column mapping mode doesn't support it
Fix: Enable column mapping mode on the affected table in Databricks:
ALTER TABLE <catalog>.<schema>.<table> SET TBLPROPERTIES ('delta.columnMapping.mode' = 'name');
"schema not found" or "catalog not found"
Cause: catalog_name or schema_name is misspelled, or credentials lack access
Fix: Verify the exact catalog and schema names in Databricks. Check that the service principal or PAT user has access to both.
64 MB gRPC document size limit
Cause: Very large documents exceeding the gRPC message size limit
Fix: Use field selection to exclude large fields, or create a derivation to truncate oversized documents before materializing.
"Merge query too large"
Cause: Too many bindings or too many fields in a single materialization
Fix: Split into multiple materializations with fewer bindings, or use field selection to reduce the number of fields per binding.
PAT re-entry needed after backfill
Cause: Known issue where PAT may need to be re-entered after triggering a backfill
Fix: Re-enter the same PAT in the connector configuration. This is a known UI quirk, not a credential expiration.
SQL Warehouse auto-stopped
Cause: SQL Warehouse stopped due to inactivity timeout
Fix: Ensure the SQL Warehouse auto-stop timeout is set long enough, or the connector will restart it automatically on the next sync cycle. Set auto-stop to minimum if cost permits.
Materialization stuck in PENDING
Wait 30-60 seconds — this is normal during shard assignment. If still stuck:
flowctl logs --task <TENANT>/<PATH>/materialize-databricks --since 5m | jq 'select(.level == "error")'
Related Skills
schema-field-selection — Control which fields are materialized
connector-disable-enable — Pause/restart existing materializations
connector-delete-recreate — Nuclear option for stuck materializations
estuary-logs — Deep log analysis
estuary-catalog-status — Status checking