Writing to Unity Catalog-Managed Tables with Starburst

Databricks’ Unity Catalog-managed tables allow the catalog to fully own Delta Lake transaction state using catalog-managed commits, all while keeping data in open object storage.

With the August 2026 LTS, Starburst now supports both reading from and writing to catalog-managed tables. This means that you can now use Unity Catalog for governance and table management while leveraging Starburst as a high‑performance, federated SQL engine accessing all your data sources. This integration is the result of close collaboration between the Product and Engineering teams at Starburst and Databricks, and was jointly presented at the Data + AI Summit in 2025.

This post breaks down what this means, including:

• What catalog-managed tables and commits are
• Why they matter for Starburst users
• How they’re supported in Starburst Enterprise and Starburst Galaxy
• A basic demo to get started

What are catalog‑managed tables?

At a high level, Unity Catalog manages Delta tables. It does so in three different ways:

• External tables: Data lives in your own object storage, and Unity Catalog stores its identity, schema, and storage location. Commits are coordinated via the filesystem, as with traditional Delta tables.
• Managed tables: Unity Catalog owns both the data and metadata of the table in its own managed bucket. Commit coordination still runs through the filesystem, like with external tables.
• Catalog‑managed tables with catalog-managed commits: Managed tables, but with commit coordination happening through Unity Catalog. Writers will propose commits to Unity Catalog, which will accept or reject them.

From a Delta Lake perspective, catalog-managed tables are identified by the delta.feature.catalogManaged writer/reader feature in the Delta protocol, set at table creation time in Databricks.

For the rest of this post, “catalog-managed tables” refer to the third type of table. You may still see the older term catalog-owned tables in earlier discussions and docs. In current Databricks and Starburst documentation, catalog-managed is the canonical name.

Why catalog‑managed tables matter for Starburst users

Unity Catalog allows many organizations to standardize governance and access control. However, those organizations may also want:

• Compute choice: allowing the ability to run workloads on Starburst, not only on the native Databricks engine.
• Federated analytics: allowing users to join catalog‑managed Delta tables with data in other warehouses, operational stores, and lakes with a single SQL layer.
• Open storage: including data in Amazon S3, ADLS, or GCS, that is not locked inside a proprietary format.

Catalog‑managed commits allow Databricks users to manage and govern Delta tables from a single catalog. Starburst builds on that to give you:

• Full CRUD on governed Delta tables from Starburst: INSERT, UPDATE, MERGE, DELETE, and DROP against compatible tables.
• Centralized governance in Unity Catalog with cross‑source SQL in Starburst: supporting joins across Delta, Iceberg, Hive, JDBC sources, and more.
• Short‑lived credentials via credential vending: Starburst never needs long‑lived access keys to your data buckets

Starburst is steadily investing in the Delta Lake connector, making it a state-of-the-art offering for these workloads.

How Starburst supports catalog‑managed tables

In Starburst Enterprise, the Delta Lake connector documents support for catalog-managed commits when Unity Catalog is configured as the metastore on AWS, Azure, or Google Cloud.

Here’s what Starburst’s compatibility looks like for each table type:

• External tables and Catalog-managed tables
  • INSERT, UPDATE, MERGE, DELETE, DROP, SELECT
• Managed tables
  • Read‑only

Catalog‑managed tables are therefore the managed table type you should standardize on when you want governed writes from both Databricks and Starburst.

Architecture at a glance

When you query a catalog‑managed table from Starburst:

• Starburst uses Unity Catalog REST APIs as the metastore. It resolves table metadata, locations, and table IDs for catalog‑managed Delta tables.
• For data access, Starburst relies on:
  • Unity Catalog’s credential vending to request short‑lived credentials scoped to the table ID or external location
  • The underlying Delta log and data files in S3, ADLS, or GCS
• When you perform a write (INSERT, UPDATE, MERGE, DELETE), Starburst:
  • Writes data and log fragments into the correct storage locations
  • Collaborates with Unity Catalog’s commit logic to finalize the transaction

This design keeps governance and commit authority in Unity Catalog, while Starburst focuses on query planning, federation, and performance.

Catalog‑managed table support in Starburst Enterprise

1. Configure Unity Catalog as the metastore

First, configure your Delta Lake Unity catalog in Starburst Enterprise to talk to Unity Catalog.

connector.name=delta_lake
-- Use Unity integration
delta.security=allow-all
hive.metastore.unity.host=<DATABRICKS_HOST>
hive.metastore.unity.token=<PERSONAL_ACCESS_TOKEN>
hive.metastore.unity.catalog-name=<UNITY_CATALOG_NAME>
-- Enable Unity Catalog-managed tables with catalog-managed commits
hive.metastore.unity.catalog-managed-table-enabled=true
-- Optional: enable credential vending from Unity Catalog
hive.metastore.unity.vended-credentials-enabled=true

Add this to your catalog configuration to allow Starburst to recognize and write to catalog-managed tables.

2. Create catalog‑managed tables in Databricks

On the Databricks side, create catalog‑managed tables with the delta.feature.catalogManaged feature enabled.

CREATE TABLE main.default.orders_uc_managed (
  id     bigint,
  name   string
)
USING delta
TBLPROPERTIES (
  'delta.feature.catalogManaged' = 'supported',
  'delta.enableRowTracking' = 'false',
  'delta.checkpointPolicy' = 'classic'
);

Today, Starburst expects these properties:

• delta.feature.catalogManaged = 'supported'
• delta.enableRowTracking = 'false'
• delta.checkpointPolicy = 'classic'

Databricks enables some advanced features (row tracking, checkpoint v2, domain metadata) by default for catalog‑managed tables that external engines do not yet fully support.

As Databricks evolves these defaults and third‑party support, Starburst will track the upstream changes. Always check the latest Delta Lake Unity connector docs for any updated table property recommendations.

3. Verify reads and writes from Starburst

Once Unity Catalog is configured and catalog‑managed tables exist, you can exercise them from Starburst Enterprise just like any other Delta catalog:

-- Read from the catalog-managed table
SELECT *
FROM unity_delta.default.people_uc_managed;

-- Insert 2 rows: Alice and Bob
INSERT INTO unity_delta.default.people_uc_managed (id, name)
VALUES
    (1, 'Alice'),
    (2, 'Bob');

-- Update 1 row: change Bob to Charlie
UPDATE unity_delta.default.people_uc_managed
SET name = 'Charlie'
WHERE id = 2;

-- Perform a MERGE for upserts (insert or update id/name)
MERGE INTO unity_delta.default.people_uc_managed t
USING staging.people_changes s
ON (t.id = s.id)
WHEN MATCHED THEN
  UPDATE SET name = s.name
WHEN NOT MATCHED THEN
  INSERT (id, name)
  VALUES (s.id, s.name);

-- Clean up: delete Charlie
DELETE FROM unity_delta.default.people_uc_managed
WHERE name = 'Charlie';

These operations are governed by Unity Catalog policies but executed through Starburst, giving you Databricks‑aligned governance and Starburst‑grade federation and performance.

Using catalog‑managed tables from Starburst Galaxy

Starburst Galaxy supports Unity Catalog as a metastore, including reads and writes to catalog-managed tables through a Unity catalog type in the Galaxy UI.

To get started:

1. In Starburst Galaxy, go to Data → Catalogs → Create catalog.
2. Choose Unity as the data source and select your cloud provider.
3. Provide the Unity Catalog connection details (host, token, catalog name) and test the connection.
4. Attach the catalog to a cluster and set appropriate permissions.
5. From the Galaxy query editor, run SELECT, INSERT, UPDATE, MERGE, and DELETE operations against your Unity Catalog tables, including catalog‑managed ones.

Governance remains in Unity Catalog, and Galaxy handles the compute and federation.

When to use catalog‑managed tables vs external tables

Using catalog-managed tables and external tables separately means that knowing when to use each table type is now important. 

Use catalog‑managed tables when:

• You want Unity Catalog to fully manage table lifecycle and commits.
• You plan to use a mix of Databricks and Starburst on the same logical tables under unified governance.
• You want tighter integration with Unity’s credential vending and table‑ID–based access control.

Use external tables when:

• You’re migrating from an existing Delta layout and want minimal changes to how data is organized.
• You need fine‑grained control over locations, prefixes, and bucket aliases.
• You’re primarily using Starburst as the compute engine and Unity as a metadata and policy layer over externally managed data.

In many architectures, you’ll use both. For example, you might use external tables for legacy or shared layouts, and catalog‑managed tables for new, governed workloads where managed commits simplify operations.

Why Starburst catalog-managed tables matter

To recap, catalog‑managed tables give Databricks users a governed, managed Delta table type that’s friendly to external engines. T

With write support for these tables, Starburst lets you:

• Keep Unity Catalog as the source of truth for governance and metadata
• Run high‑performance, federated SQL across Delta and dozens of other systems
• Maintain open data formats on object storage, with short‑lived, scoped credentials via Unity’s credential vending

If you’re standardizing on Unity Catalog but want more flexibility and performance across your whole data estate, catalog‑managed table support in Starburst is the connective tissue that makes interoperable compute a reality.

Want to know more about Starburst and Databricks interoperability? Read more here.