Cloud Parts

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.

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-enterprise feature 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 →
Apache FlinkOpen sourceThe most widely used open-source engine for stateful stream processing: keyed state, event time and exactly-once recovery from checkpoints.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.Cloudflare Basin PipelinesRenamedCommercialCloudflare’s managed streaming ingestion service, called Cloudflare Pipelines until October 2026, that takes events over HTTP or a Workers binding, transforms them with SQL and writes them to R2 as Apache Iceberg tables, Parquet or JSON.DenormalizedArchivedOpen sourceAn embeddable stream processing library in Rust, with Python bindings, built on Apache DataFusion. Abandoned since December 2024 at version 0.0.13.Kafka StreamsOpen sourceA Java library, part of Apache Kafka, that turns your own application into a stateful stream processor with no cluster of its own.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.RisingWaveOpen sourceA streaming database in Rust that speaks the PostgreSQL protocol: you write materialized views in SQL, and it keeps them up to date as events arrive, with all state in object storage.StreamFusionOpen sourceAn open-source accelerator for Apache Flink SQL: Flink still plans and coordinates the job, while the operators it can reproduce exactly run natively in Rust on Arrow and DataFusion.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

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 runsA single container on one node (Docker, or from source)Your Kubernetes cluster, cloud or on premises; one pod per pipeline
SQL and connectorsFull SQL, all connectors, state larger than memoryThe same
Checkpoints and fault toleranceNoCheckpoints every 60 seconds by default, at-least-once or exactly-once recovery, sync to S3 for disaster recovery
Change the SQL, keep the stateNo: a modified program starts from scratchYes: only new or modified views are recomputed
Scale-outNoMulti-host pipelines (preview) and parallel compilation
Security extrasNot includedOIDC and SSO, roles, Kubernetes secrets and IAM roles for service accounts
PriceFree; community support on SlackCustom pricing

Other engines that keep SQL results fresh#

RisingWave

Apache 2.0

A 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.1

Strongly 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.0

Continuous 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

  1. 2018

    Differential Datalog starts at VMware Research

  2. 2021

    Database Stream Processor repository started at VMware in December

  3. 2022

    Budiu and Ryzhyk define the DBSP theory

  4. 2023

    Best Paper award at VLDB in August; Feldera, Inc. announced with seed funding

  5. 2026

    Enterprise code joins the repository under separate terms in May

  6. 2026

    $21.5 million Series A and seed announced in September

Sources29 · facts checked 6 October 2026

Improve this page on GitHub