TL;DR
Databricks materialized views cache pre-computed query results and refresh them incrementally, so BI dashboards and ETL pipelines read from stored data rather than recomputing from scratch on every query. Every materialized view is backed by a serverless Lakeflow pipeline and governed through Unity Catalog. In 2026, refresh policies and EXPLAIN CREATE MATERIALIZED VIEW reached GA, Delta Sharing for MVs entered public preview, and metric view materialization launched as a new public preview feature. This guide covers how MVs work, how to create and schedule them, governance, monitoring, and when to use them over streaming tables or standard views.
BI dashboards that recompute the same complex aggregations on every single refresh. ETL pipelines running full scans across terabytes of data that barely changed. Query latency climbing week over week as data volumes grow, even though the underlying logic never changed. These are symptoms of a missing layer in the lakehouse. Precomputed, governed, and incrementally refreshed results address each one directly.
Databricks materialized views address this directly. They cache query results as physical tables, refresh them incrementally when source data changes, and serve precomputed output to every downstream consumer without requiring any changes to the query layer. Refresh policies and EXPLAIN CREATE MATERIALIZED VIEW reached general availability in 2026. Metric view materialization entered public preview in June 2026. The feature set is now mature enough for production workloads at enterprise scale.
This guide covers how Databricks materialized views work under the hood, how they compare to standard views and streaming tables, what changed in 2026, how to create and govern them through Unity Catalog, and when they actually deliver measurable gains.
Key Takeaways A Databricks materialized view caches pre-computed query results in cloud storage, refreshes them incrementally when source data changes, and returns those results faster than recomputing from source tables on every query. Materialized views differ from standard views, which recompute on every query, and streaming tables, which process append-only data continuously. Choosing the right type depends on freshness requirements and data change patterns. Every materialized view is backed by a Lakeflow Spark Declarative Pipeline , either created automatically for standalone MVs or defined explicitly in pipeline source code. Refresh policies, EXPLAIN CREATE MATERIALIZED VIEW, and Delta Sharing for MVs all reached GA or public preview in 2026, making the feature set significantly more production-ready. Unity Catalog governs materialized views at the output layer, including column masking, row-level security, and Delta Sharing to external recipients.Metric view materialization, in public preview since June 2026, lets teams pre-compute aggregations for semantic layer metrics and have the query optimizer route queries to the right granularity automatically.
Ready to build faster, more efficient data pipelines? Discover how Kanerika helps you unlock the full value of Databricks.
Book a Meeting
What Are Databricks Materialized Views? A Databricks materialized view is a database object that stores the pre-computed results of a query as a physical table in cloud storage. Unlike a standard view , which reruns the underlying query every time it is accessed, a materialized view returns cached results directly. The query engine only touches source data when the materialized view is refreshed.
Unity Catalog registers the materialized view as a governed object. The cached data lives in the workspace’s default storage location, separate from the source tables. Every materialized view is backed by a Lakeflow Spark Declarative Pipeline that handles refresh orchestration.
1. Standalone MVs vs Pipeline-Defined MVs Two creation paths exist. Standalone materialized views are created from a Pro or Serverless SQL warehouse, or from a notebook on serverless general compute. Databricks automatically provisions a serverless Lakeflow pipeline in the background to manage refreshes. The pipeline is visible in the Jobs and Pipelines list, but engineers do not configure it directly.
Pipeline-defined materialized views are created explicitly inside Lakeflow Spark Declarative Pipelines source code, using either the @dp.materialized_view Python decorator or a CREATE MATERIALIZED VIEW SQL statement within the pipeline definition. This path suits multi-table pipelines, layered medallion architectures, and cases where multiple materialized views share refresh governance under a single pipeline.
Table 1: Standalone MVs vs Pipeline-Defined MVs
Dimension Standalone Materialized View Pipeline-Defined Materialized View Creation interface Pro or Serverless SQL warehouse, or notebook Lakeflow Pipeline source code Backing pipeline Auto-provisioned serverless Lakeflow pipeline Explicit pipeline definition Best for Single-table use cases, quick deployment Multi-table pipelines, medallion architecture Refresh governance Per-MV schedule or trigger Pipeline-level orchestration Visibility Jobs and Pipelines list (MV/ST type) Jobs and Pipelines list (ETL type) SQL syntax CREATE OR REPLACE MATERIALIZED VIEW Same syntax inside pipeline source
Understanding which path to use is the first architectural decision before writing any MV SQL.
Standard Views vs Materialized Views vs Streaming Tables These three object types serve different purposes in a Databricks lakehouse. Conflating them leads to mismatched architectures.
Table 2: Standard Views vs Materialized Views vs Streaming Tables
Dimension Standard View Materialized View Streaming Table Storage None, virtual only Cached results in cloud storage Append-only Delta table Refresh model Recomputes on every query Schedule, trigger, or manual Continuous or triggered Query performance Depends on source table size Fast, reads precomputed data Depends on table size Data freshness Always current As of last refresh Near real-time Incremental support No Yes, where possible Yes (append-only) Source data type Any Batch or slowly changing Append-only streams Unity Catalog Yes Yes Yes Best use case Simple abstraction Aggregations, ETL, BI Real-time ingestion
The practical decision follows from two questions. How fresh does the data need to be? If minutes or hours are acceptable, a materialized view with a scheduled refresh works. If seconds matter, streaming tables are the right fit. Is the source data append-only? Streaming tables are optimized for that pattern. Most aggregation, ETL, and BI workloads fall into the materialized view category.
Standard views remain the right choice when there is no performance problem to solve. They work well for simple column aliases, row filters, or access control abstractions over tables that are queried infrequently. With the three types defined, it helps to understand what specifically changed in 2026 before going further.
Source: Databricks What Changed in Databricks Materialized Views in 2026 The 2026 release cycle made materialized views significantly more production-ready. Teams building on this feature in 2024 or early 2025 were working with a less complete feature set. The changes this year are substantial enough that the implementation decisions that made sense eighteen months ago need revisiting.
The GA releases that matter most in production:
Refresh policies GA: Teams now have control over timeout behavior and retry logic beyond basic CRON scheduling, which was the most common gap in production MV deploymentsEXPLAIN CREATE MATERIALIZED VIEW GA: Engineers can estimate refresh cost before committing to a schedule. This is the primary tool for right-sizing refresh frequency against DBU cost before a refresh runsStandard performance mode for MV refreshes in jobs: A lower-cost compute option for non-serverless refresh workloads, giving teams more flexibility in how they structure production pipelines
The public preview additions worth tracking:
Predictive optimization for MV backing tables: OPTIMIZE and VACUUM on backing tables now run automatically, removing the manual maintenance overhead that previously required separate job schedulingDelta Sharing for materialized views: MVs can now be shared with external recipients across workspaces and organizations. One constraint carries weight for cross-team architectures: a materialized view can only be refreshed in the workspace where it was created, even when shared externallyMetric view materialization (June 2026): Extends materialized views to the semantic layer, pre-computing aggregations for metric views defined in YAML and routing queries to the best-fit materialization automatically
How Databricks Materialized Views Work Under the Hood 1. The Pipeline Architecture Behind Every Materialized View Every materialized view is backed by a Lakeflow Spark Declarative Pipeline . This pipeline manages the refresh process, reading from source tables, computing transformations, and writing results to the MV’s backing storage. For standalone MVs, Databricks provisions this pipeline automatically.
The backing pipeline is visible in the Jobs and Pipelines list. Standalone MV pipelines appear with the MV or ST type designation. Pipeline-defined MVs appear as ETL. Unity Catalog stores the MV metadata, including schema, refresh schedule, and lineage. Teams using Databricks Autoloader for incremental ingestion often pair it with materialized views at the Silver and Gold layers. The backing tables that support incremental refresh exist in internal storage and are not visible in Catalog Explorer. This is intentional. Exposing them would create downstream access and PII exposure risks.
2. Incremental Refresh and How Databricks Minimizes Compute Cost Incremental refresh is the primary performance advantage of Databricks materialized views over manually managed aggregation tables. Instead of recomputing the entire MV from source data on each refresh, Databricks identifies what changed in source tables since the last refresh and processes only those rows.
This requires row tracking to be enabled on the source Delta tables. When row tracking is available and the MV query is incrementally supportable, Databricks processes only the changed rows. Deletion vectors , enabled by default for new MVs since April 2025, reduce the merge overhead on incremental refreshes significantly.
Full recomputes are triggered when the query contains non-deterministic functions such as rand() or now(), when row tracking is not available on source tables, or when certain complex aggregation patterns fall outside the incremental refresh scope. Teams should test with EXPLAIN CREATE MATERIALIZED VIEW before deploying a complex MV to a production schedule.
Table 3: Incremental Refresh vs Full Refresh
Dimension Incremental Refresh Full Refresh What it processes Only rows changed since last refresh Entire source dataset Compute cost Low, scales with change volume High, scales with source table size Requires Row tracking on source Delta tables Nothing additional Triggered by Default when conditions are met Non-deterministic functions, no row tracking Best for Large tables with frequent small changes Small tables or complex aggregations Syntax to force Default behavior REFRESH MATERIALIZED VIEW view_name FULL
3. The Fast Path and Fallback Path at Query Time When a query arrives that touches a table covered by a materialized view, the Databricks query optimizer evaluates whether to serve pre-computed results (the fast path) or read from source data (the fallback path). This decision is transparent to the querying user. The same SQL query returns results from either path without modification.
Aggregate-aware query rewriting handles cases where a query does not exactly match the MV definition but can still benefit from its pre-computed aggregates. A dashboard query asking for weekly regional sales can be served by an MV that pre-computed daily regional sales. The optimizer chooses the most efficient path based on what is available and what governance policies apply. With the architecture understood, the next step is creating MVs in practice.
Creating Databricks Materialized Views 1. Standalone Materialized Views Creating a standalone materialized view requires a Pro or Serverless SQL warehouse, or a notebook on serverless general compute. The SQL syntax for a standalone MV follows this pattern.
sql
CREATE OR REPLACE MATERIALIZED VIEW regional_sales
AS
SELECT
partners.region,
SUM(sales.amount) AS total_sales,
COUNT(*) AS transaction_count
FROM partners
INNER JOIN sales ON partners.partner_id = sales.partner_id
GROUP BY partners.region;Executing this statement creates the MV, runs the initial data load synchronously, and provisions the backing serverless pipeline. The MV is immediately queryable after the initial load completes.
2. Pipeline-Defined Materialized Views Inside a Lakeflow Spark Declarative Pipeline, materialized views are defined using the @dp.materialized_view decorator in Python or the CREATE MATERIALIZED VIEW statement in SQL pipeline source files. This path is preferable when multiple MVs share dependencies, when the pipeline handles Bronze-to-Silver-to-Gold layering, or when refresh governance needs to be managed at the pipeline level rather than per-MV.
The syntax inside a pipeline is identical to the standalone SQL syntax. The primary difference is that the pipeline controls the refresh schedule and orchestration, not the individual MV definition.
3. Refresh Policies and Scheduling Manual refresh uses REFRESH MATERIALIZED VIEW view_name. Scheduled refresh is set with an ALTER statement as shown below.
sql
ALTER MATERIALIZED VIEW regional_sales
SET SCHEDULE CRON '0 0 * * *' AT TIME ZONE 'America/Chicago';Refresh policies, now GA, add timeout and retry configuration beyond the basic schedule. The default timeout for MVs created after August 2025 is two days. Teams with long-running MVs should configure explicit timeout values to avoid unexpected failures. TRIGGER ON UPDATE is available for event-driven refresh, triggering a refresh when any source table referenced by the MV is updated. Databricks Workflows can also orchestrate MV refresh as part of a broader pipeline dependency chain.
4. Adding Data Quality Expectations Data quality constraints can be embedded directly in the MV definition using the CONSTRAINT clause, as in the example below.
sql
CREATE OR REPLACE MATERIALIZED VIEW validated_orders
(CONSTRAINT valid_amount EXPECT (total_sales > 0) ON VIOLATION DROP ROW)
AS SELECT ...ON VIOLATION FAIL UPDATE stops the entire refresh on a constraint violation. ON VIOLATION DROP ROW filters out violating rows and continues. Both options write results to the event log, which integrates with Unity Catalog data quality monitoring for tracking constraint pass rates over time.
Governance of the MV layer does not stop at the table level. Unity Catalog extends control to the query and sharing layer as well.
Materialized Views and Unity Catalog Governance Most articles about Databricks materialized views treat them as a query performance feature. The data governance layer is at least as important for enterprise teams, and most competitor content skips it entirely.
1. Access Controls and Column Masking on Materialized Views Unity Catalog governs access to materialized views at the output layer, independently of the source tables. SELECT, REFRESH, and MANAGE privileges are separate grants. A reporting team can hold SELECT on the MV without holding SELECT on the underlying source tables. This matters when source tables contain sensitive columns that should not be exposed directly.
Column masking policies apply to MV output columns. Row-level security is enforced at query time on the MV. One behavior worth tracking is that when row-level security or column masking is applied to an MV, the query optimizer cannot use the MV for query rewrites. The fallback path reads from source tables instead. Governance and query performance are a trade-off when masking is required at the MV layer.
2. Delta Sharing for Materialized Views Delta Sharing support for materialized views reached public preview in 2026. An MV can be shared to external recipients, including other Databricks workspaces, Fabric environments, or any Delta Sharing-compatible platform, using standard Delta Sharing syntax. Refresh can only happen in the workspace where the MV was created. External recipients receive read access to the pre-computed results but cannot trigger a refresh.
For data mesh architectures where domain teams publish curated datasets to consumers, this behavior is a natural fit. The producing domain controls data freshness; consumers get fast, governed read access.
3. Lineage and Discovery in Catalog Explorer Catalog Explorer shows column-level data lineage from source tables through the materialized view to downstream consumers. Refresh history, current status, and last refresh timestamp are all visible in the UI. DESCRIBE EXTENDED returns detailed metadata including last refresh timestamp and structured refresh metadata in JSON format using DESCRIBE EXTENDED AS JSON.
Lineage appears for both standalone and pipeline-defined MVs, though the display differs slightly between the two in the current UI. Knowing how to monitor MVs after deployment is as important as knowing how to build them.
Monitoring and Observability for Materialized Views 1. Checking Refresh Status Three places surface refresh status. Catalog Explorer shows refresh history for the MV, including success, failure, and in-progress states. DESCRIBE EXTENDED on the MV returns the current status, last refresh timestamp, and pipeline backing the MV. The Jobs and Pipelines list includes MV-backing pipelines, making it possible to monitor refresh health alongside other pipeline workloads.
2. Debugging Failed Refreshes Failed refreshes produce an event log entry in the backing pipeline. DESCRIBE EXTENDED AS JSON returns structured refresh metadata including the failure reason, which is faster to parse than scanning pipeline event logs manually.
Common failure patterns include upstream schema changes that invalidate the MV definition, timeout configuration mismatches for long-running MVs, and resource constraints on the backing compute. Refresh policies now support retry logic, reducing transient failures without manual intervention.
3. Cost Monitoring for Refresh Operations Each refresh consumes DBU compute. The cost varies significantly between incremental and full refreshes. A full recompute on a large aggregation table can cost far more than an incremental pass over changed rows. EXPLAIN CREATE MATERIALIZED VIEW returns a cost estimate before the refresh runs. This is the right tool for evaluating a new MV’s refresh schedule before it hits production.
Teams seeing unexpectedly high full-recompute frequency should check whether row tracking is enabled on source tables and whether the MV query contains non-deterministic functions. For a broader look at tuning strategies, Kanerika’s Databricks performance optimization guide covers additional levers. Predictive optimization now handles OPTIMIZE and VACUUM on MV backing tables automatically, removing a category of hidden maintenance cost that previously required manual scheduling.
How Metric View Materialization Works in Databricks (June 2026) 1. What Metric View Materialization Does Metric views are YAML-defined semantic objects that describe business metrics in a central, reusable format. Before June 2026, metric views computed aggregations at query time. This was useful for consistency but not for performance at scale. Metric view materialization , now in public preview, pre-computes those aggregations as materialized views and stores the results in cloud storage. This is part of Databricks’ broader data intelligence platform investment in the semantic layer.
At query time, the Databricks query optimizer routes queries to the best available materialization using aggregate-aware query rewriting. The querying user writes a standard metric query; the optimizer decides whether to serve pre-computed results or fall back to source data. Changes to the query layer are not required.
2. How to Configure Metric View Materialization Materialization is defined in the metric view YAML configuration. Teams specify aggregated or unaggregated materialized views, configure the refresh schedule and granularity, and define which dimensions the pre-computation covers. Lakeflow Spark Declarative Pipelines orchestrates the refresh lifecycle.
The fast path applies when a suitable materialization exists at the right granularity. The fallback path applies when no materialization covers the query’s required grain, in which case the metric view computes from source data. Both paths return correct results; only performance differs.
3. Why This Matters for Semantic Layers Business metrics defined in a metric view YAML file become the single source of truth for calculation logic. Materialization pre-computes those metrics at one or more granularities, including daily, weekly, regional, or by product line. Queries that roll up across granularities benefit from the appropriate pre-computed layer without the team managing multiple aggregation tables manually.
This matters because the previous pattern, maintaining separate pre-aggregation tables per BI tool or dashboard, frequently diverges over time when calculation logic is maintained in multiple places independently.
Databricks Lakeflow: What It Is & How Teams Use It Learn how Databricks Lakeflow simplifies data ingestion, orchestration, and pipeline management for scalable, reliable data engineering.
Learn More
When to Use Databricks Materialized Views 1. BI Dashboards and Reporting BI tools query the same aggregation logic repeatedly, often on every dashboard refresh. Running those aggregations against source tables introduces latency and consumes warehouse compute that scales with data volume, not query complexity. Materialized views break that relationship. A regional sales summary MV refreshed on a schedule is available instantly to every BI consumer without recomputing the underlying join each time.
2. Medallion Architecture Layering Bronze-to-Silver-to-Gold pipelines implemented as a series of materialized views gain two advantages. Each layer refreshes incrementally based on what changed in the layer below, rather than reprocessing full history. The transformation logic lives in SQL, version-controlled alongside pipeline definitions, rather than scattered across Spark notebooks or ADF pipelines with complex data engineering dependency chains.
3. ETL Simplification and CDC Materialized views replace complex imperative ETL jobs for aggregation, denormalization, and correction workloads. The declarative model, writing the SQL that defines the output and letting Databricks handle refresh orchestration, reduces operational complexity. Change data capture patterns work naturally with incremental refresh when row tracking is enabled on the source tables.
4. Compliance and Data Corrections Regulated industries that need audit-ready data transformations benefit from MVs in two ways. Data quality expectations embedded in the MV definition act as a runtime compliance enforcement layer. Access History in Unity Catalog captures who queried the MV and when, providing the audit trail that financial services, healthcare, and insurance teams need.
Limitations Worth Knowing Before You Build Storage cost and refresh cost grow with MV complexity and refresh frequency. Right-sizing the refresh schedule against actual freshness requirements is the most direct way to control MV cost. Teams evaluating compute options should also read how Databricks serverless pricing compares to classic warehouse costs. EXPLAIN CREATE MATERIALIZED VIEW provides a pre-run cost estimate that makes this decision concrete rather than guesswork.
Teams choosing between platforms can also compare architectures in Kanerika’s Databricks vs Snowflake breakdown.
Table 4: Databricks Materialized View Limitations Summary
Limitation Detail Workaround Compute requirement Pro or Serverless SQL warehouse required for standalone MVs Use Standard performance mode for refresh jobs Workspace restriction Can only be refreshed in the workspace where created Share read access via Delta Sharing to external recipients Identity columns Not supported Use surrogate keys generated upstream in the pipeline Non-deterministic functions Trigger full recompute instead of incremental Remove rand(), now(), uuid() from MV query Column masking Disables query optimizer rewrites when applied Apply masking on downstream views, not the MV itself Time Travel Not supported on MV backing tables Query source Delta tables directly for time travel Change Data Feed (CDF) Cannot read CDF from an MV Use streaming tables for CDC patterns that require CDF Cross-workspace refresh Not possible even when shared via Delta Sharing Maintain refresh ownership in the source workspace
Migrating Existing Pipelines to Databricks Materialized Views 1. From Traditional ETL Jobs The migration candidate profile is specific. The right targets are jobs that run on a schedule, read from Delta tables, and write to aggregated output tables. These jobs do exactly what a materialized view does, but with manual orchestration, no incremental refresh, and no Unity Catalog lineage.
The migration path is to convert the job’s transformation logic to a CREATE OR REPLACE MATERIALIZED VIEW SQL statement, configure a refresh schedule matching the job’s run interval, and decommission the job. Incremental refresh typically reduces compute cost significantly compared to the original full-scan job, making cost-per-run a measurable data modernization benefit — a pattern covered in depth in Kanerika’s enterprise data modernization guide.
2. From Delta Live Tables and Lakeflow Pipelines Delta Live Tables is now Lakeflow Spark Declarative Pipelines. Teams already using DLT materialized views are already on the right architecture. The MV syntax inside Lakeflow pipelines is identical to the standalone MV syntax, so existing pipeline definitions do not need to change. What does change is the broader management experience. Teams gain unified pipeline visibility, refresh policies, and GA status for features that were previously in preview.
3. From Standard Views Performance-impacted standard views are the clearest migration candidates. If a view’s execution plan shows expensive aggregations or joins running on large source tables, converting it to a materialized view with an appropriate refresh schedule will reduce query latency for downstream consumers. The conversion uses CREATE OR REPLACE MATERIALIZED VIEW with the same query as the existing view. Testing fast path behavior after conversion validates whether the optimizer routes queries through the MV as expected.
Databricks Data Engineering: How Kanerika Implements Materialized Views in Production Kanerika is a Databricks Consulting Partner with data engineering implementations across manufacturing, retail, financial services, and logistics. In practice, the materialized view pattern addresses a recurring architectural gap. Analytics teams sitting downstream of complex lakehouse pipelines built for throughput, not query performance, end up absorbing the latency cost at the consumption layer.
The typical data architecture Kanerika implements separates ingestion (streaming tables for append-only event data), transformation (pipeline-defined materialized views for Silver layer aggregations), and serving (standalone materialized views at the Gold layer for data analytics consumption). Unity Catalog governs each layer, and lineage flows column-level from Bronze through to the dashboard.
Karl: AI-Powered Analytics on Pre-Computed Manufacturing Data Karl, Kanerika’s AI Data Insights agent, operates on pre-aggregated analytics layers in manufacturing and retail environments. Pre-computed materialized views at the Gold layer allow Karl to retrieve aggregated inventory, sales, and production metrics without querying raw transactional data on every request. In a manufacturing client engagement, this architecture contributed to 65% time savings on data analysis workflows, 5x faster delivery of business insights, and 78% improvement in team efficiency.
Challenges Distributed on-premise PostgreSQL and Cassandra databases created data silos with no centralized lineage, governance, or consistent visibility across business units and downstream applications High infrastructure and maintenance overhead consumed IT capacity in hardware upkeep, backup management, and scaling work that limited focus on analytics and business growth Production application dependencies made a standard cutover approach too risky, migration had to run with zero downtime and full parallel availability until each system was verified
Solution Kanerika designed a three-phase migration framework using PySpark notebooks and Spark connectors to migrate full historical data from PostgreSQL and Cassandra into Delta Lake tables under Unity Catalog-managed schemas. Continuous incremental synchronization used timestamp-based CDC-style logic and Delta MERGE operations, keeping source databases live throughout the transition. Each application was redirected to Databricks workspaces individually after validation, with on-premise infrastructure decommissioned only after full confirmation.
Results 100% centralized governance with all on-premises data consolidated into a single cloud platform 100% legacy infrastructure decommissioned, eliminating hardware and backup overhead Zero-downtime migration with uninterrupted business operations Centralized governance using Unity Catalog for RBAC, authentication, and data lineage
Wrapping Up Databricks materialized views have moved well past preview status. The 2026 GA milestones for refresh policies, cost estimation, and Delta Sharing, combined with the June 2026 metric view materialization preview, make this a feature set worth building on in production. The organizations getting the most out of them treat materialized views not as a performance trick, but as a governed architectural layer between transformation and consumption. That distinction determines whether MVs actually reduce cost and latency, or simply add complexity. For teams ready to implement this at scale, Kanerika’s Databricks data engineering practice covers production architecture, governance setup, and migration from legacy pipelines.
FAQs What are Databricks materialized views? A Databricks materialized view is a Unity Catalog object that stores the pre-computed results of a SQL query as a physical table in cloud storage. Unlike standard views that recompute on every query, materialized views return cached results. They refresh incrementally when source data changes, and every MV is backed by a Lakeflow Spark Declarative Pipeline that manages the refresh process.
How do materialized views differ from standard views and streaming tables? Standard views recompute their query on every access and always reflect the current state of source tables. Materialized views cache results and refresh on a schedule or trigger, making them faster for repeated queries on slowly changing data. Streaming tables process continuously arriving, append-only data in near real-time. The right choice depends on freshness requirements and whether the source data is append-only or batch.
How does incremental refresh work in Databricks materialized views? Incremental refresh reads only the rows that changed in source tables since the last refresh, rather than reprocessing the entire source dataset. It requires row tracking to be enabled on the source Delta tables. When the query contains non-deterministic functions or when row tracking is unavailable, Databricks falls back to a full recompute. Deletion vectors, enabled by default for new MVs since April 2025, reduce merge overhead on incremental refreshes.
What compute is required to create a Databricks materialized view? Creating and refreshing standalone materialized views requires a Pro or Serverless SQL warehouse, or a notebook running on serverless general compute. Standard performance mode for MV refresh jobs is now available as a lower-cost option. Pipeline-defined MVs run on the compute configured for the Lakeflow pipeline. Classic SQL warehouses do not support MV creation or refresh.
How do I schedule a refresh for a Databricks materialized view? Use ALTER MATERIALIZED VIEW view_name SET SCHEDULE CRON ‘…’ AT TIME ZONE ‘…’ to configure a scheduled refresh. For event-driven refresh, use TRIGGER ON UPDATE to refresh when any referenced source table is updated. Manual refresh uses REFRESH MATERIALIZED VIEW view_name. Refresh policies (now GA) add timeout and retry configuration beyond basic scheduling.
Can Databricks materialized views be shared across workspaces? Yes, with constraints. Delta Sharing for materialized views reached public preview in 2026, allowing MVs to be shared to external recipients across workspaces or organizations. However, a materialized view can only be refreshed within the workspace where it was created. External recipients receive read access to the pre-computed results but cannot trigger a refresh from their workspace.
What are the main limitations of Databricks materialized views? The main limitations are that standalone MVs require a Pro or Serverless SQL warehouse; identity columns and surrogate keys are not supported; non-deterministic functions in the MV query trigger full recompute instead of incremental refresh; row filters or column masks on the MV disable query optimizer rewrites; MVs can only be refreshed in their origin workspace; and Time Travel queries against MV backing tables are not supported.
What is metric view materialization in Databricks? Metric view materialization, in public preview since June 2026, allows pre-computing aggregations for metric views defined in YAML. Lakeflow Spark Declarative Pipelines orchestrates the refresh. At query time, the Databricks query optimizer automatically routes queries to the best available pre-computed materialization using aggregate-aware query rewriting. This removes the need to manually manage multiple pre-aggregation tables for different BI query granularities.
