--- title: Databend Incremental Materialized Views - Change... description: Databend's new incremental materialized view design stores results in an independent, read-only FUSE table, separate from the source table, using Change... canonical: https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Databend Incremental Materialized Views - Change Tracking, Incremental Refresh, and Consistent Reads | daily.dev og:description: Databend's new incremental materialized view design stores results in an independent, read-only FUSE table, separate from the source table, using Change... og:url: https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i og:image: https://api.daily.dev/og/posts/nOmQfsR5i.png og:image:alt: Databend Incremental Materialized Views - Change Tracking, Incremental Refresh, and Consistent Reads og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Databend Incremental Materialized Views - Change Tracking, Incremental Refresh, and Consistent Reads **[Databend Blog](https://daily.dev/sources/databend)** · 13 min read · 0 upvotes · 0 comments ## Summary Databend's new incremental materialized view design stores results in an independent, read-only FUSE table, separate from the source table, using Change Tracking (built on existing Stream semantics) and checkpoints to track source consumption progress. Refresh work runs asynchronously and chooses between full rebuild and incremental append-only processing depending on the change set. At query time, Databend picks a Fresh, Hybrid (read fix), or Live Fallback plan to guarantee correctness even when refresh lags behind: Fresh reads the MV directly, Hybrid merges unmaterialized append-only deltas at query time, and Live Fallback bypasses the MV entirely when updates, deletes, or garbage-collected snapshots make compensation unsafe. Aggregate MVs persist mergeable state (not final scalars) and periodically reaggregate, compact, and recluster to control fragmentation. The feature is best suited to single-table, append-heavy analytical workloads such as logs and event data, and is less suited to multi-table joins or frequent updates/deletes. It shipped in Databend Enterprise Edition after v1.2.934. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does Databend guarantee correct query results when a materialized view refresh has fallen behind the source table? Databend compares the source snapshot recorded in the materialized view's checkpoint against the source table's current snapshot at query time. If they match, it uses the Fresh path reading the MV directly. If the MV lags but all changes since the checkpoint are append-only, the Hybrid path merges the unmaterialized delta at query time. If updates, deletes, an incomplete initial refresh, or a garbage-collected snapshot make compensation unsafe, Databend falls back to executing the query against the source table (Live Fallback), so a stale refresh only adds cost, never incorrect results. _Track database engineering deep dives like materialized view consistency models on daily.dev._ ### What is the difference between Databend's old Aggregating Index and its new materialized view feature? Aggregating Index is a block-level projection attached to and constrained by the source table's own blocks and maintenance, with no independent consumption endpoint, so a changed source block usually requires rebuilding its index. The new materialized view is stored as an independent FUSE table with its own cluster key, blocks, and maintenance strategy, tracks a separate source checkpoint and snapshot, and can be compacted or reclustered independently of the source table. _Compare evolving storage designs like this one for databases on daily.dev._ ### What kinds of workloads are a good fit for Databend's incremental materialized views? They work best for single-table, continuously ingested, append-heavy analytical workloads such as logs, events, and behavioral data, where historical rows are rarely updated or deleted, allowing each refresh to process only the unconsumed interval. They also suit write-throughput-sensitive systems needing non-stale answers and cases where ingestion and analytics need different physical layouts. Multi-table joins, frequent updates or deletes, and fully automatic scheduling are not yet well supported. _Weigh workload fit before adopting new database features using daily.dev._ ## Similar posts on daily.dev - [ClickHouse Materialized Views: How They Work and Where They Break](https://daily.dev/posts/clickhouse-materialized-views-how-they-work-and-where-they-break-nsi75zjaa) · BigData Boutique blog · 1 upvotes · 0 comments - [Materialized Lake Views in Microsoft Fabric: When Your Medallion Fits in a SELECT Statement](https://daily.dev/posts/materialized-lake-views-in-microsoft-fabric-when-your-medallion-fits-in-a-select-statement-ggimppmdc) · Towards Data Science · 0 upvotes · 0 comments - [Self-Correcting Materialized Views](https://daily.dev/posts/self-correcting-materialized-views-fbqfma2ff) · Materialize · 0 upvotes · 0 comments - [Migrate Oracle Materialized Views with AWS DMS and Fast Refresh](https://daily.dev/posts/migrate-oracle-materialized-views-with-aws-dms-and-fast-refresh-jqtwqal7t) · AWS Database Blog · 0 upvotes · 0 comments - [Gaps and Islands in ClickHouse: Moving a Window Function Into Materialized Views](https://daily.dev/posts/gaps-and-islands-in-clickhouse-moving-a-window-function-into-materialized-views-9wdfklrpo) · BigData Boutique blog · 0 upvotes · 0 comments --- Tags: [#data-warehouse](https://daily.dev/tags/data-warehouse), [#change-data-capture](https://daily.dev/tags/change-data-capture) [View this post on daily.dev](https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Databend Incremental Materialized Views - Change Tracking, Incremental Refresh, and Consistent Reads","url":"https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i"},"datePublished":"2026-09-02T08:27:41.136Z","dateModified":"2026-09-02T08:32:13.765Z","description":"Databend's new incremental materialized view design stores results in an independent, read-only FUSE table, separate from the source table, using Change...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/cfa3ef43f3fd28fe51f49a13e67f7457?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/cfa3ef43f3fd28fe51f49a13e67f7457?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Databend Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Databend Blog","logo":"https://media.daily.dev/image/upload/s--Vkqa36Ma--/f_auto,q_auto/v1786870423/logos/databend?_a=BAMAMicg0","url":"https://daily.dev/sources/databend"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"data-warehouse,change-data-capture","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Databend Blog","item":"https://daily.dev/sources/databend"},{"@type":"ListItem","position":3,"name":"Databend Incremental Materialized Views - Change Tracking, Incremental Refresh, and Consistent Reads"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/databend-incremental-materialized-views---change-tracking-incremental-refresh-and-consistent-reads-nomqfsr5i#faq","mainEntity":[{"@type":"Question","name":"How does Databend guarantee correct query results when a materialized view refresh has fallen behind the source table?","acceptedAnswer":{"@type":"Answer","text":"Databend compares the source snapshot recorded in the materialized view's checkpoint against the source table's current snapshot at query time. If they match, it uses the Fresh path reading the MV directly. If the MV lags but all changes since the checkpoint are append-only, the Hybrid path merges the unmaterialized delta at query time. If updates, deletes, an incomplete initial refresh, or a garbage-collected snapshot make compensation unsafe, Databend falls back to executing the query against the source table (Live Fallback), so a stale refresh only adds cost, never incorrect results. Track database engineering deep dives like materialized view consistency models on daily.dev."}},{"@type":"Question","name":"What is the difference between Databend's old Aggregating Index and its new materialized view feature?","acceptedAnswer":{"@type":"Answer","text":"Aggregating Index is a block-level projection attached to and constrained by the source table's own blocks and maintenance, with no independent consumption endpoint, so a changed source block usually requires rebuilding its index. The new materialized view is stored as an independent FUSE table with its own cluster key, blocks, and maintenance strategy, tracks a separate source checkpoint and snapshot, and can be compacted or reclustered independently of the source table. Compare evolving storage designs like this one for databases on daily.dev."}},{"@type":"Question","name":"What kinds of workloads are a good fit for Databend's incremental materialized views?","acceptedAnswer":{"@type":"Answer","text":"They work best for single-table, continuously ingested, append-heavy analytical workloads such as logs, events, and behavioral data, where historical rows are rarely updated or deleted, allowing each refresh to process only the unconsumed interval. They also suit write-throughput-sensitive systems needing non-stale answers and cases where ingestion and analytics need different physical layouts. Multi-table joins, frequent updates or deletes, and fully automatic scheduling are not yet well supported. Weigh workload fit before adopting new database features using daily.dev."}}]} ```