
Feldera
An incremental view maintenance engine in Rust: you write SQL tables and views, and it keeps every view up to date by processing only the changes, based on the award-winning DBSP theory.
- What it is
- Stream processing
- Type
- Open source
- Made by
- Feldera, Inc.
- License
- MIT for the open-source edition (the Rust crates are published as MIT OR Apache-2.0); since May 2026 the repository also contains Enterprise-only code, behind a
feldera-enterprisefeature flag, that needs a paid licence. The engine began at VMware Research, also under MIT - Facts checked
- 6 October 2026
What it is
A Feldera pipeline is a SQL program: CREATE TABLE statements are the inputs and CREATE VIEW statements the outputs, and views can build on views. Feldera’s compiler, written in Java on Apache Calcite, turns the program into a Rust program on DBSP (Database Stream Processor), compiles it and runs it as one process. Connectors attached to each table in a WITH clause feed it changes, meaning inserts and deletes (an update is both): Kafka topics, HTTP, Debezium or PostgreSQL CDC, Delta Lake, Iceberg, S3 files, Pub/Sub and others. DBSP represents each batch of changes as a Z-set, rows with a weight of +1 or -1, and computes exactly how every view changes, using indexes it keeps for joins and aggregates; that state can grow larger than memory and spill to disk. The result is the same as rerunning every query in a batch engine, but the work is proportional to the change, not to the data. View changes go out through sink connectors (Kafka, Delta Lake, PostgreSQL, Snowflake, Redis, DynamoDB); Iceberg output goes through Kafka Connect. Feldera keeps a view’s full contents only if it is declared MATERIALIZED, and those can be queried ad hoc through Apache DataFusion. LATENESS on a timestamp column tells it how late events may arrive, so it can drop state it will never need again.
The open-source edition, free under MIT, runs a pipeline on a single node in a single container, with full SQL and every connector. Feldera Enterprise runs in your Kubernetes cluster with one pod per pipeline and adds checkpoints, fault tolerance and disaster recovery, changing a running program without losing its state, multi-host pipelines (in preview), SSO and role-based access, at custom prices. The engine comes from VMware Research, where Mihai Budiu and Leonid Ryzhyk developed DBSP; their paper won a Best Paper award at VLDB 2023, the year they and three colleagues founded Feldera.
Why teams pick it
- Evaluates whole SQL programs incrementally, including joins, aggregates, correlated subqueries, window functions, recursive queries and stacks of views, with results that match a batch run on the same input
- Work is proportional to the size of each change, so the same SQL can backfill history and then keep up with live data
- Built on a peer-reviewed theory: DBSP won a VLDB 2023 Best Paper award, and its maths has been formalised in the Lean theorem prover
- A single Rust process with state that can exceed memory, and connectors for Kafka, CDC, Delta Lake, Iceberg, warehouses and databases
Watch out for
- The free edition has no checkpoints or fault tolerance: after a crash or restart a pipeline must re-ingest its inputs, and changing a program while keeping its state is Enterprise-only too
- Not a database: no transactions or concurrency control, views aren’t stored unless materialized, and applications usually read results from a sink
- Every change to the SQL compiles a new Rust program before the pipeline can start; Enterprise offers parallel compilation to speed this up
- Licensing is now mixed: the MIT core shares the repository with Enterprise code under Feldera’s terms (GitHub shows the licence as NOASSERTION), and Enterprise prices aren’t published
- Some connectors are experimental, such as PostgreSQL CDC and Iceberg input, and recursive queries use Feldera’s own syntax rather than standard SQL
Alternatives
What all stream processing have in common →
ArroyoOpen sourceA stream processing engine in Rust: you write the pipeline as SQL, and it keeps windows and joins running with checkpointed state.
BytewaxOpen sourceA Python stream processing framework on a Rust engine built on Timely Dataflow; its company wound down in 2025 and the last release is from November 2024.
ksqlDBCommercialConfluent’s SQL server for Kafka: queries that run forever, turning topics into new topics and into tables you can look up.
PathwayCommercialA Python framework for streaming ETL and live RAG pipelines: you write table transformations in Python, and a Rust engine built on Differential Dataflow keeps the results up to date.
Quix StreamsOpen sourceA pure-Python library for stateful stream processing on Kafka: a pandas-like Streaming DataFrame, RocksDB state backed up to Kafka, and no cluster of its own.
Redpanda ConnectRenamedOpen sourceFormerly Benthos: one Go binary that runs a YAML pipeline of inputs, processors and outputs, with at-least-once delivery and no disk state of its own.
StreamlingCommercialGoldsky’s young Rust pipeline runtime: YAML pipelines of stateless SQL, TypeScript and plugin steps on Arrow, from Kafka or files into Postgres, ClickHouse or webhooks.Timely DataflowOpen sourceA Rust library for data-parallel dataflow with logical timestamps, loops and exact progress tracking; the engine underneath Materialize.How it fits with other technologies
What Feldera uses
- Felderareads inputs from and writes views toApache Kafka
- Felderareads CDC from and writes view changes toPostgreSQL
- Felderareads and writes tables inDelta Lake
- Felderareads tables (experimental) fromApache Iceberg
- Felderareads input files fromAmazon S3
- Felderawrites view changes toSnowflake
- Felderawrites view changes toRedis
- Felderaanswers ad-hoc queries withApache DataFusion
- Felderaruns each pipeline as a pod (Enterprise) onKubernetes
What uses Feldera
A Feldera program: two input tables, a materialized join, and a view streamed to Kafka · sql
CREATE TABLE purchases (
purchase_id BIGINT NOT NULL,
customer_id BIGINT NOT NULL,
amount DECIMAL(12, 2) NOT NULL,
ts TIMESTAMP NOT NULL LATENESS INTERVAL 1 HOURS -- at most an hour out of order
) WITH ('connectors' = '[{
"transport": {
"name": "kafka_input",
"config": {"bootstrap.servers": "kafka-1:9092", "topic": "purchases", "start_from": "earliest"}
},
"format": {"name": "json", "config": {"update_format": "insert_delete", "array": false}}
}]');
-- filled through the REST API, a file or a CDC connector
CREATE TABLE customers (
customer_id BIGINT NOT NULL PRIMARY KEY,
country VARCHAR NOT NULL
);
-- kept up to date from changes only; a customer moving country updates both rows
CREATE MATERIALIZED VIEW revenue_by_country AS
SELECT c.country, COUNT(*) AS purchases, SUM(p.amount) AS revenue
FROM purchases p JOIN customers c ON p.customer_id = c.customer_id
GROUP BY c.country;
-- each change to this view is sent to Kafka as an insert or a delete
CREATE VIEW big_spenders
WITH ('connectors' = '[{
"transport": {"name": "kafka_output", "config": {"bootstrap.servers": "kafka-1:9092", "topic": "big-spenders"}},
"format": {"name": "json", "config": {"update_format": "insert_delete", "array": false}}
}]')
AS SELECT customer_id, SUM(amount) AS total
FROM purchases
GROUP BY customer_id
HAVING SUM(amount) > 10000;Open-source and Enterprise editions#
From Feldera’s pricing page and docs, checked 2026-10-06.
| Open source (MIT) | Enterprise | |
|---|---|---|
| Where it runs | A single container on one node (Docker, or from source) | Your Kubernetes cluster, cloud or on premises; one pod per pipeline |
| SQL and connectors | Full SQL, all connectors, state larger than memory | The same |
| Checkpoints and fault tolerance | No | Checkpoints every 60 seconds by default, at-least-once or exactly-once recovery, sync to S3 for disaster recovery |
| Change the SQL, keep the state | No: a modified program starts from scratch | Yes: only new or modified views are recomputed |
| Scale-out | No | Multi-host pipelines (preview) and parallel compilation |
| Security extras | Not included | OIDC and SSO, roles, Kubernetes secrets and IAM roles for service accounts |
| Price | Free; community support on Slack | Custom pricing |
Other engines that keep SQL results fresh#
RisingWave
Apache 2.0A streaming database that speaks the PostgreSQL wire protocol and keeps tables, views and internal state in object storage, so applications query materialized views directly. Premium features need a licence key.
Materialize
BSL 1.1Strongly consistent views over PostgreSQL, MySQL and Kafka sources, queried over the PostgreSQL protocol. Free use is limited to installations under 24 GiB of memory and 48 GiB of disk.
Flink SQL
Apache 2.0Continuous queries over dynamic tables in Apache Flink, also equivalent to batch results on a snapshot. A distributed framework that writes results to other systems rather than serving them.
See it in a real stack
No architecture uses Feldera yet. Drop it into the playground and wire it up yourself.Open playground →Where it came from2018–2026
In 2018 Leonid Ryzhyk and Mihai Budiu at VMware Research started Differential Datalog, a library for computing over continuously changing data. By around 2020 it ran in VMware Skyline’s cloud service for thousands of customers, but watching developers write their rules convinced the team they needed a better experience, and SQL was familiar. Budiu and Ryzhyk went back to the theory and, in 2022, defined DBSP, a small algebra of streams that can turn any query into one that processes only changes, with proofs that the result matches recomputing from scratch.
Their paper with Tej Chajed, Frank McSherry and Val Tannen won a Best Paper award at VLDB 2023. In August 2023 they announced Feldera, the company, with Lalith Suresh, Ben Pfaff and Gerd Zellweger from VMware and seed funding led by Costanoa; the MIT-licensed code moved from VMware to the new company, by then with a SQL compiler built on Apache Calcite and an engine in Rust.
Feldera has since moved from streaming toward replacing batch jobs that rerun over mostly unchanged data. In May 2026 it began keeping Enterprise code in the same repository under separate terms, and in September 2026 it announced $21.5 million in Series A and seed funding led by Inovia Capital.
Why it’s built this way
- A theory first, then the engine
- The team had seen general incremental engines fail through engineering alone. DBSP gives provably correct rules for each operator and a recipe for adding new ones without breaking correctness.
- SQL instead of Datalog
- Differential Datalog worked in production, but the team wanted a better developer experience and SQL was familiar and well understood, so DBSP was built to evaluate full SQL, including recursion.
- Compile each program to Rust
- Translating SQL into a specialised Rust program, rather than interpreting a plan, gives native speed and memory safety without a garbage collector.
- Consistency over approximation
- Feldera guarantees that view contents always equal what a batch system would compute on the same input, so incremental results can replace batch jobs.
Timeline
- 2018
Differential Datalog starts at VMware Research
- 2021
Database Stream Processor repository started at VMware in December
- 2022
Budiu and Ryzhyk define the DBSP theory
- 2023
Best Paper award at VLDB in August; Feldera, Inc. announced with seed funding
- 2026
Enterprise code joins the repository under separate terms in May
- 2026
$21.5 million Series A and seed announced in September
- Feldera blog: Announcing Feldera, the company (26 August 2023)
- Feldera blog: DBSP wins Best Research Paper, VLDB 2023 (28 August 2023)
- Budiu, Chajed, McSherry, Ryzhyk, Tannen: DBSP, Automatic Incremental View Maintenance for Rich Query Languages (PVLDB 16, 2023)
- Feldera: About us (founders, VMware since 2018)
- GitHub: feldera/feldera LICENSE history (VMware 2021, Enterprise section added May 2026)
- Feldera blog: Announcing our Series A and Seed (21 September 2026)
Sources29 · facts checked 6 October 2026
- Feldera docs: What is Feldera? (pipelines, features)
- Feldera docs: SQL introduction (DBSP, compiled to Rust, not a database)
- Feldera docs: Materialized tables and views
- Feldera docs: Ad-hoc queries (Apache DataFusion)
- Feldera docs: Recursive queries
- Feldera docs: Time-series extensions (LATENESS)
- Feldera docs: Time series analysis guide (LATENESS syntax and state cleanup)
- Feldera docs: Connectors
- Feldera docs: Kafka input connector
- Feldera docs: Kafka output connector
- Feldera docs: PostgreSQL CDC input connector (experimental)
- Feldera docs: Iceberg input connector (experimental)
- Feldera docs: Delta Lake output connector
- Feldera docs: Iceberg output through Kafka Connect (no direct Iceberg sink)
- Feldera docs: Fault tolerance and disaster recovery (Enterprise-only)
- Feldera docs: Modifying a pipeline while preserving its state (Enterprise-only)
- Feldera docs: Enterprise edition architecture (pod per pipeline, multi-pod preview)
- Feldera docs: Parallel compilation (Enterprise)
- Feldera docs: Publications and awards (VLDB 2023 Best Paper, Lean formalisation)
- Feldera blog: Z-sets, representing database changes
- Feldera pricing (open source MIT, Enterprise custom pricing)
- GitHub: feldera/feldera README
- GitHub: feldera/feldera LICENSE (MIT open-source edition, Enterprise section)
- GitHub: feldera/feldera Cargo.toml (crates licensed MIT OR Apache-2.0)
- GitHub: Feldera releases (v0.361.0, October 2026)
- GitHub: RisingWave README (Postgres protocol, state in object storage, Apache 2.0)
- GitHub: Materialize LICENSE (BSL 1.1, 24 GiB memory and 48 GiB disk grant)
- GitHub: Materialize README (consistency, sources, PostgreSQL protocol)
- Flink docs: Dynamic tables and continuous queries