Databricks

Nobody has run Databricks against LakehouseBox yet, so this page has no recipe and claims nothing works. It sets out what Databricks' own documentation says about reaching an Iceberg catalog that Databricks does not run (as read on 2026-10-04), and which route someone would have to try.

What Databricks documents

Unity Catalog cannot attach a LakehouseBox catalog today. Databricks reads Iceberg tables from another catalog as foreign Iceberg tables, through catalog federation. The catalogs it lists for catalog federation are Hive metastores, AWS Glue, Snowflake, Salesforce Data 360, Palantir Foundry and Workday Data Connect (Lakehouse Federation, Iceberg in Databricks); a general Iceberg REST catalog is not one of them. Foreign Iceberg tables are read-only in Databricks either way.

Unity Catalog reaches the files through an external location, and catalog federation needs one for the table paths (Lakehouse Federation). Databricks lists AWS S3 and Cloudflare R2 as the storage for external locations on AWS (cloud storage), with Azure Data Lake Storage and Google Cloud Storage on the other clouds. The page has no option for an S3-compatible endpoint of your own.

Managed Iceberg and UniForm go the other way. Managed Iceberg tables are stored in Databricks' own catalog and storage, and outside engines reach them through Databricks' Iceberg REST endpoint (managed tables, Iceberg clients). UniForm gives Iceberg readers access to Delta tables, read-only (UniForm). Neither puts tables in a LakehouseBox catalog.

The route left to test: the Iceberg Spark runtime on a classic cluster

LakehouseBox's verified Spark recipe (Spark) is plain Apache Spark with the open-source Iceberg runtime: a catalog named in spark.sql.catalog.*, our catalog URL and credentials, and the storage endpoint https://s3.lakehousebox.com with region us-east-1. On Databricks that would mean installing iceberg-spark-runtime and iceberg-aws-bundle on a cluster and setting the recipe's lines in its Spark configuration. What Databricks says about that:

• Not on serverless compute. Serverless notebooks take no JAR libraries, no Maven coordinates and no Spark extensions, and refuse most Spark settings (serverless limitations).
• Standard access mode is restricted. JARs and Maven coordinates must be on the metastore's allowlist (allowlist), some Spark settings are refused, and Databricks points to dedicated compute when those features are needed (standard compute limitations).
• Databricks does not support it. From Databricks Runtime 14.3 LTS the runtime carries its own Iceberg data source, and Databricks' knowledge base says external Iceberg JARs are "no longer supported", after a clash between the two (Multiple sources found for iceberg) (knowledge base).

What has not been run: whether a classic cluster in dedicated access mode with these jars and the recipe reads and writes LakehouseBox tables. The recipe reaches tables through its named catalog rather than the iceberg data source, so it may not meet that clash, but nobody knows until someone tries. If it works, Unity Catalog governs none of it: the Iceberg client talks to LakehouseBox's catalog and storage with LakehouseBox's own credentials. Our verified Spark combinations are Spark 3.5 with Iceberg 1.11 and Spark 4.1 with Iceberg 1.12; the jars would have to match the cluster's Spark and Scala versions.

Through Snowflake

Snowflake reads and writes LakehouseBox tables, and Snowflake is a query federation source in Databricks (Lakehouse Federation). A Databricks query could in principle reach a LakehouseBox table that way, with Snowflake doing the reading. That has not been run either.

If you try any of this, tell us what happened, working or not: the line below goes to us, and a recorded run is what turns this page into a recipe.