Databricks has spent years building materialized views that precompute and cache query results inside its own SQL warehouses, making dashboards and BI faster. The catch was always that those MVs spoke Delta, not Iceberg, so if your platform mix includes Trino, Spark on Kubernetes, or anything else that reads open table formats, your carefully maintained MV was invisible to it. That changes with managed Iceberg materialized views, which entered Public Preview on July 7, 2026 and let you create a materialized view that external Iceberg readers can query directly. For teams running mixed Databricks and open-source stacks, this is the feature that reframes the lock-in conversation.
The feature writes MV results to Apache Iceberg instead of Delta Lake, which means any engine with an Iceberg reader can open the same physical files your Databricks SQL warehouse produced.
What are managed Iceberg materialized views?
A materialized view is a precomputed result set stored as a table and refreshed on a schedule or trigger. Databricks SQL has supported them for a while, letting you accelerate expensive aggregations, joins, and transformations by computing once and reading many times.
The new twist is the storage format. Standard Databricks materialized views are written to Delta Lake tables. Managed Iceberg materialized views write to Apache Iceberg instead. Any engine with an Iceberg reader, including Trino, Apache Spark, and DuckDB, can query the same physical table your Databricks SQL warehouse produced. You get the precompute benefit inside Databricks and the portability benefit outside it.
The feature is in Public Preview. To enable it, you need to contact your Databricks account team; there is no self-service toggle in the workspace UI. Databricks documents the setup under Create a materialized view compatible with external Iceberg readers in the July 2026 release notes.
The distinction matters because it changes how you think about MVs on this platform. If your analytics estate is purely Databricks, standard Delta MVs are simpler and fully supported. If a second engine needs the same precomputed results, Iceberg MVs eliminate the need to maintain a parallel copy or export pipeline.
How do you configure them?
Since this is Public Preview and account-team-gated, the first step is contacting your Databricks representative to enable the feature for your workspace. Once enabled, the creation path mirrors standard materialized views but directs the output to Iceberg-format storage.
A typical materialized view definition follows the standard Databricks SQL pattern:
CREATE MATERIALIZED VIEW catalog.schema.daily_revenue
COMMENT 'Daily revenue by region, Iceberg-readable'
AS
SELECT region, order_date, SUM(amount) AS revenue
FROM catalog.schema.orders
GROUP BY region, order_date;The exact property or catalog configuration that targets Iceberg rather than Delta is described in the Databricks documentation linked above. The refresh happens on a schedule or on demand, the same as a standard MV. What changes is that the resulting table is queryable by any Iceberg-compatible engine that can reach your catalog storage.
Refreshes can also take advantage of REPLACE WHERE flows, which became generally available on July 7, 2026. REPLACE WHERE lets you replace only the rows matching a predicate on each refresh without reprocessing the full table history. For a daily-revenue MV partitioned by date, that means you can recompute just yesterday's partition instead of rebuilding the entire view. This applies to pipelines and standalone streaming tables as well.
What does it cost you?
Materialized view refreshes consume compute, and Iceberg MVs are no exception. The cost story has two relevant updates from the July 2026 release.
First, materialized view and streaming table refreshes in Databricks SQL now inherit custom tags from the enclosing SQL warehouse environment, as of July 8, 2026. These tags propagate to system.billing.usage, so you can attribute refresh costs back to the source SQL warehouse. If you have been unable to figure out which warehouse is paying for which MV refresh, this closes that gap for both Delta and Iceberg MVs alike.
Second, materialized view and streaming table refreshes orchestrated through a SQL task in a Lakeflow job now respect the job's performance-optimized setting, as of July 6, 2026. When you turn that setting off, the refresh uses standard performance mode, which consumes fewer DBUs than the performance-optimized default. For Iceberg MVs that refresh on a schedule, choosing standard mode when latency is not critical is a straightforward way to cut the refresh bill.
Here is how the two modes compare:
| Setting | Performance mode | Standard mode |
|---|---|---|
| DBU consumption | Higher | Lower |
| Refresh speed | Faster | Slower |
| When to use | SLA-sensitive refreshes | Overnight or batch refreshes |
| Configurable via | Lakeflow job SQL task setting | Same setting, toggled off |
The cost attribution tags work regardless of which performance mode you choose. You can read more about managing compute spend in our Databricks Lakeflow Designer cost guide, which covers the same tag-based attribution pattern for pipeline workloads.
The chart below shows the illustrative difference in DBU consumption between performance and standard mode for scheduled MV refreshes at three data volumes. Standard mode uses roughly 30 percent fewer DBUs in this example, though the exact ratio depends on your query complexity, data volume, and warehouse size. Treat the numbers as directional, not as a Databricks-published rate.
When are they the right choice?
The use case is narrow but compelling. You should consider managed Iceberg materialized views when a second compute engine outside Databricks needs to query your precomputed results, and you are already paying to maintain a parallel copy or export pipeline that duplicates MV logic in another system. Trino and Spark on Kubernetes are the most common examples.
Another fit is when your governance or contractual requirements mandate open table formats for downstream consumption, or when you want to evaluate a migration away from Databricks for read workloads without rewriting your transformation logic.
If none of those apply, standard Delta materialized views remain the simpler choice. They are GA, fully supported, and do not require an account-team conversation to enable. The Iceberg format adds a portability tax in the form of preview-stage limitations and format overhead that is not worth paying if only Databricks will ever read the table.
The feature also fits into the broader Databricks Data Intelligence Platform story of meeting open-format demand without forcing teams off the platform. Unity Catalog governs both Delta and Iceberg tables, so permissions, lineage, and auditing apply consistently across formats.
What are the limits in Public Preview?
Public Preview means the feature is real but not finished. Several constraints are worth flagging before you build a production pipeline around it.
- Account-team enablement required. There is no self-service toggle. You file a request and wait.
- Staged rollout. Databricks stages releases across accounts, so your workspace may not have the feature for a week or more after the July 7 date, and you should expect rough edges in edge cases.
- Refresh semantics. Incremental refresh and REPLACE WHERE support depend on the underlying MV's partitioning and the query pattern. Not every MV can be refreshed incrementally; some require full recomputation.
- External reader compatibility. Iceberg is a standard, but engine versions matter. Verify that your Trino or Spark version supports the Iceberg table version and features Databricks writes. Format divergence between writer and reader is a real risk in mixed stacks.
You should also confirm how Databricks bills the Iceberg-format MV refresh versus the Delta equivalent. The release notes do not call out a separate pricing tier, which suggests the same DBU model applies, but Public Preview pricing can change. Check the Databricks pricing page for current rates before committing.
What should you do next?
If you have a mixed-engine stack, the bet to make is small and deliberate. Pick one MV that a non-Databricks engine already needs, enable the feature, and migrate that single view to Iceberg format. Measure the refresh cost, the read latency from both engines, and any format-compatibility issues. That tells you whether to expand.
The bet to skip is a wholesale migration of all MVs to Iceberg format on day one. Public Preview is for validation, not for replatforming your entire semantic layer. If your team is purely on Databricks, there is no reason to move yet.
Watch for the GA announcement, which will likely remove the account-team gate and add self-service enablement. Also watch for any changes to how Unity Catalog exposes Iceberg MV metadata, since lineage and access audit across formats is where governance complexity tends to hide.
The lock-in question has a new answer
The strongest argument against building your semantic layer inside Databricks has always been that the output is Delta and the rest of the world is moving toward Iceberg. Managed Iceberg materialized views do not eliminate lock-in, but they give you a credible exit ramp for read workloads, and they let you serve two engines from one precomputed table. For a data engineer who has been maintaining duplicate pipelines just to feed Trino, that is the detail worth testing in Public Preview.
Sources
- Databricks: Managed Iceberg materialized views in Public Preview (July 2026 release notes)
- Databricks: Automatic cost attribution for materialized views and streaming tables (July 2026 release notes)
- Databricks: Standard performance mode for MV refreshes in jobs (July 2026 release notes)
- Databricks: REPLACE WHERE flows generally available (July 2026 release notes)
- Databricks pricing
