Compare
Where OpenIVM fits.
Most incremental systems are either a separate streaming engine you feed with change data, or a feature of one managed warehouse. OpenIVM is a compiler that runs inside the engine you already use and emits plain SQL.
| System | What it is | Where it runs | When views update | Incremental SQL coverage | License |
|---|---|---|---|---|---|
| OpenIVM | IVM compiler (SQL in, SQL out) | Inside your engine as an extension: DuckDB today, Spark in development | On demand (PRAGMA refresh) or on a schedule (REFRESH EVERY) | Inner and outer joins, aggregates, DISTINCT, semi/anti joins, windows, CTEs; other shapes fall back to full refresh | MIT |
| pg_ivm | PostgreSQL extension | Inside PostgreSQL | Immediately, in AFTER triggers in the same transaction as each write | Joins, count/sum/avg/min/max, DISTINCT, EXISTS, simple CTEs; no window functions, HAVING, UNION, or aggregates over outer joins | PostgreSQL License |
| Materialize | Streaming data warehouse (Differential Dataflow) | Separate system, fed by change data capture or Kafka | Continuously, as changes arrive | Broad SQL, maintained as streaming dataflows | Business Source License (source-available) |
| Feldera | IVM engine built on DBSP | Separate pipeline engine | Continuously, as changes arrive | Broad SQL, compiled to DBSP circuits | MIT (open-source edition) |
| RisingWave | Streaming database | Separate system, PostgreSQL wire protocol | Continuously, as changes arrive | Broad streaming SQL | Apache 2.0 |
| Snowflake Dynamic Tables | Managed warehouse feature | Inside Snowflake | To a target lag; each refresh is incremental or full | Documented list of incrementally refreshable constructs | Proprietary |
| Databricks materialized views | Managed lakehouse feature | Inside Databricks, on serverless pipelines | On a schedule or trigger; incremental when possible, best effort | Documented list of incrementally refreshable constructs | Proprietary |
Summarized from each project's public documentation and repository, September 2026. Spotted something out of date? Open an issue.
What sets OpenIVM apart.
- The output is SQL. The maintenance program is ordinary SQL you can read, test and run elsewhere, not a runtime you have to operate. See what it generates.
- No second system. No change-data-capture pipeline or separate cluster: views are maintained inside DuckDB, and soon Spark, over ordinary batch tables.
- Open and research-backed. MIT-licensed, built at CWI Amsterdam, and described in a SIGMOD 2024 paper.
When something else fits better.
- You need freshness on every write. A streaming system (Materialize, Feldera, RisingWave) or pg_ivm's immediate maintenance updates views as changes arrive; OpenIVM refreshes on demand or on a schedule.
- You want a managed service on your warehouse. Snowflake Dynamic Tables and Databricks materialized views are built into those platforms.
- Your query is a small single-table aggregate. DuckDB recomputes these so fast that incremental refresh has little to win; the gains come with joins and larger data.