Databricks and Apache Iceberg: OLake Go guides
Databricks reads Apache Iceberg tables that live in Unity Catalog. OLake Go writes straight into that catalog.
Short answer. To copy a database to Databricks, point OLake Go at the Unity Catalog Iceberg REST (representational state transfer) endpoint. The tables land as managed Iceberg tables, and on these Databricks reads only v3 deletion vectors. Add Databricks as a target query engine and OLake Go writes them from the first sync.
Key takeaways
- OLake Go writes Unity Catalog managed Iceberg tables that Databricks governs and queries directly.
- With Databricks as a target query engine, OLake Go writes Iceberg v3 deletion vectors from the first sync.
- Eight guides ran end to end on Unity Catalog, with DuckDB and Spark reading the same tables.
Last reviewed October 2026.
How OLake Go gets data into Databricks
OLake Go uses change data capture (CDC) for Postgres, MySQL, MariaDB, MongoDB and SQL Server, and commits each sync to Unity Catalog. Databricks, DuckDB and Spark then read the same tables. Tables in AWS Glue or Hive Metastore show up in Databricks only as read-only foreign tables.
The eight guides below ran on a 2X-Small serverless SQL warehouse. The Unity Catalog writer page holds the full destination reference.
When to use it
- Databricks is the main reader and Unity Catalog holds your data.
- You want the same rows readable from DuckDB or Spark without a second copy.
When not to use it
- You need to upsert a Kafka topic on an older OLake. Before Kafka source v1.1.1 and OLake UI v0.8.2, Kafka upserts use positional deletes, which Unity Catalog tables do not take, so Kafka runs in Append mode. Current versions upsert with deletion vectors, as in Kafka to Databricks.
- Athena or another engine on the job cannot read deletion vectors. OLake Go needs one delete format that all target engines read.
Catalogs Databricks reads
| Catalog | Databricks reads | How |
|---|---|---|
| AWS Glue | Partial | foreign Iceberg tables through catalog federation (read-only) |
| Unity Catalog | Yes | native: Unity Catalog managed Iceberg tables |
| Hive Metastore | Partial | foreign Iceberg tables through catalog federation (read-only) |
Delete formats Databricks reads
| Equality deletes (v2) | Positional deletes (v2) | Deletion vectors (v3) |
|---|---|---|
| No | No | Yes |
Under Unity Catalog, Databricks does not read Iceberg v2 position or equality deletes. Only Iceberg v3 deletion vectors work, so the OLake Go job must use deletion vectors from the first sync. Set Databricks as a target query engine on the OLake Go job and OLake Go picks a format it reads; with Databricks as the only reader that is deletion vectors (v3).
Sources: Databricks: Apache Iceberg on Databricks (checked 2026-10-12); Databricks: Deletion vectors (checked 2026-10-12).
Tested guides for Databricks
- Postgres to Databricks
- MySQL to Databricks
- MariaDB to Databricks
- MongoDB to Databricks
- Oracle to Databricks
- SQL Server to Databricks
- Kafka to Databricks
- S3 to Databricks
Frequently asked questions
Does Databricks read Iceberg equality or positional deletes?
Not under Unity Catalog. Only Iceberg v3 deletion vectors work there, so the OLake Go job must use deletion vectors from the first sync.
Can DuckDB or Spark read the tables OLake Go writes to Unity Catalog?
Yes. Spark connects as an Iceberg REST client and DuckDB attaches the Unity REST endpoint. The guides below check the same rows in Databricks, DuckDB and Spark.
Why do the delete formats matter?
Each engine reads a different set of Iceberg delete files. The delete formats post explains how OLake Go picks one that every reader on the job supports.