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

# Sync Databricks data into the lakehouse

> Copy Databricks tables into a lakehouse namespace and manage refreshes and failed runs

You use a lakehouse sync to copy Databricks tables into a namespace in Olympus. Use it when you need a lakehouse copy for queries, semantic models, or transforms. The sync reads through a Databricks SQL warehouse as the person who connects the catalog, so that account's Databricks permissions control which source data it can copy.

<Frame caption="How to sync a Databricks table into the lakehouse">
  <video controls muted playsInline preload="metadata" className="w-full aspect-video" poster="/images/how-to/athena-howto-databricks-sync-poster.jpg" src="https://mintcdn.com/athenaintelligence-e46bc9d3/qz43AKUFD_YQXkyW/images/how-to/athena-howto-databricks-sync.mp4?fit=max&auto=format&n=qz43AKUFD_YQXkyW&q=85&s=875a275981ec5152850085a2cf449884" data-path="images/how-to/athena-howto-databricks-sync.mp4" />
</Frame>

<Accordion title="Steps in this video">
  1. Open your Databricks catalog and choose Sync to lakehouse
  2. Pick the target namespace
  3. Choose how to copy
  4. Type the tables
  5. Set the schedule
  6. Create the sync
  7. Run it now
  8. Check the run
  9. If it pauses, resume it
</Accordion>

## Prepare your source and destination

1. Connect Databricks with your own account using the existing Databricks connection setup.
2. Check that your account can read the source tables and use a SQL warehouse.
3. Obtain edit access to the destination lakehouse namespace. Lakehouse support must be configured on your deployment.

Only the connected catalog's owner can sync from it. Being a workspace owner or having access to another person's catalog does not replace this requirement.

## Create the sync

1. Open your connected Databricks catalog and select **Sync to lakehouse**. You can also open a namespace you can edit and select **Sync into this namespace**, then choose your catalog under **Source**.
2. Check the **Name**, which starts as "Sync" plus your catalog's name, and select **Target namespace** when it is not already fixed. Only namespaces you can edit are offered.
3. Choose **Mode**. **Snapshot (full copy)** recopies the selected tables, including source edits and deletes. **Incremental (time column)** appends rows beyond the previous cursor.
4. For incremental mode, enter a **Time column** set once when a row is created. Avoid a last-modified column: an edited row can be appended again.
5. In **Tables**, type one `catalog.schema.table` per line, using the Unity Catalog names. The **Load tables from source** button is available to administrators only, so most members type the names.
6. Choose a **Schedule**, or use on-demand execution. Custom cron schedules use UTC. Set **Freshness target (hours)** if you need an explicit target.
7. Check **Scheduled runs**, which is on by default, then select **Create sync**. The new sync asset opens.

## Refresh and inspect results

1. Open the sync and select **Run now**.
2. Find the attempt under **Runs**. Review its status, copied rows, and completed tables.
3. Expand the run to inspect each table's status, row count, watermark, and error.
4. To change the refresh definition, select **Edit definition**, make your changes, and select **Save definition**.

## Recover from a failure

1. Read the error on the sync or its failed run.
2. Check the connection, source table permissions, and SQL warehouse access. Reconnect your catalog if its credentials are no longer available.
3. If repeated failures pause the sync, fix the cause and select **Resume** before **Run now**.
4. If access is revoked, restore the required access, then edit and save the definition under an account that owns the source catalog.

## Good to know

* Viewing a sync does not grant permission to run or edit it. Running checks source access and edit access to the target namespace.
* Incremental mode does not update or delete rows already copied. Use snapshot mode when those changes must arrive.
* Each run resolves a fresh source credential. A run that outlasts that credential can fail; the next attempt resolves it again.
* **Archive** stops the sync and its schedule. Tables already copied remain in the namespace.

## Related links

* [Connect Databricks](./databricks)
* [SQL queries](../pillars/applications/query)
* [Spaces and assets](../pillars/concepts/spaces-and-assets)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.