# Fluvio: a Rust streaming engine with WASM smart modules and declarative connectors

> Fluvio is a distributed data streaming engine written in Rust, paired with a Stateful DataFlow framework for transforming data in motion. This review covers how the cluster is installed, how topics, connectors and smart modules fit together, and where the project is still thin.

**fluvio-community/fluvio** — 🦀 event stream processing for developers to collect and transform data in motion to power responsive data intensive applications.

- Repository: https://github.com/fluvio-community/fluvio
- Website: https://www.fluvio.io/
- Stars: 5,259 · Forks: 532
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/fluvio-community-fluvio

## What Fluvio is for, and who it is not for

Fluvio is a distributed data streaming engine written in Rust. The README describes it as "a lean and mean distributed data streaming engine" combined with a Stateful DataFlow framework, and the repository topics list stream processing, streaming analytics, data pipelines and WebAssembly. The intended user is a developer who needs to collect events from a source, transform them while they are in motion, and route the result somewhere else, without assembling a separate cluster, a separate stream processor and a separate connector runtime.

The streaming engine and the processing layer are one product here. Topics hold the data, connectors move it in and out, and smart modules apply transformations inside the stream. That matters if you are building an event-driven application where the transformation logic is small and the operational surface is the expensive part. It matters less if you already run a data platform and only need a message bus.

The project is not aimed at teams that want a managed service with a support contract. The README's install section carries a temporary note that the project is transitioning to a new fluvio-community hosted build and release, and it instructs readers to install the dev version of FVM in the meantime. A team that needs a frozen, supported release train is not the audience for that state of affairs.

## Architecture: control plane, SPUs, and where smart modules run

The workspace in Cargo.toml makes the split visible. There is a control plane crate, fluvio-controlplane, with metadata in fluvio-controlplane-metadata. There is an SPU crate, fluvio-spu, with its own schema crate. Storage is a separate crate, fluvio-storage. The client lives in crates/fluvio, the protocol in fluvio-protocol, and the socket layer in fluvio-socket.

That is the classic streaming layout: a control plane that tracks cluster state and metadata, and stream processing units that own partitions and serve reads and writes. The interesting part is the transformation layer. fluvio-smartengine and fluvio-smartmodule are separate crates, and the README states that Fluvio applies wasm based stream processing and data transformations, calling the reusable transformation functions smart modules. So the transformation code is compiled to WebAssembly and executed inside the stream rather than in a separate job.

Connectors are the other half. The README says first party systems can integrate through Fluvio clients at the edge, while third party systems connect at the protocol level through connectors that collect data into topics. The connector crates in the workspace (fluvio-connector-package, fluvio-connector-deployer, fluvio-connector-common, and the cdk crate for the Connector Development Kit) show that connectors are packaged and deployed as first-class objects, not as external services you wire up yourself. The trade-off is that a connector is only as good as its package, and the README itself marks several outbound connectors as experimental builds.

## Installing Fluvio with fvm and running a first topic

Fluvio installs through the Fluvio Version Manager, shortened to fvm. The README's install script is fetched with curl and piped to bash. Because the project is mid-transition, the README currently instructs readers to set FVM_VERSION=dev:

```bash
curl -fsS https://raw.githubusercontent.com/fluvio-community/fluvio/master/install.sh | FVM_VERSION=dev bash
```

After that, Fluvio lives in $HOME/.fluvio with binaries in $HOME/.fluvio/bin. The README notes that fvm also installs the Fluvio CLI from the stable channel as part of initial setup. On Windows the README recommends WSL2 for best compatibility.

You can pin versions instead of taking the default. The README gives two environment variables for this, FLUVIO_VERSION for the engine and FVM_VERSION for the version manager itself:

```bash
curl -fsS https://raw.githubusercontent.com/fluvio-community/fluvio/master/install.sh | FLUVIO_VERSION=x.y.z bash
curl -fsS https://raw.githubusercontent.com/fluvio-community/fluvio/master/install.sh | FVM_VERSION=v0.18.1 bash
```

With the CLI in place, start a local cluster and create a topic. The README's quick start uses exactly two commands for this:

```bash
fluvio cluster start
fluvio topic create hello-fluvio
```

The cluster start command brings up a local cluster on your machine. The topic create command registers a topic named hello-fluvio. If those two succeed, you have a working single-node setup.

Producing and consuming are interactive. Run the producer first, then type messages at the prompt; each accepted line returns Ok!:

```bash
fluvio produce hello-fluvio
> hello fluvio
Ok!
> test message
Ok!
```

In a second terminal, consume from the beginning and follow the stream. The README uses -B for beginning and -d for follow:

```bash
fluvio consume hello-fluvio -B -d
```

What you should see is the two messages echoed back in the consuming terminal. That is the whole local loop: one cluster, one topic, one producer, one consumer.

## Connectors, smart modules and the language clients

The README lists native inbound connectors for http, webhook, mqtt and kafka. Outbound, it lists http, SQL and kafka as supported, with DuckDB, Redis, S3 and Graphite described as experimental builds. The distinction between those two lists is the most operationally useful sentence in the README, and it is easy to skim past. If your pipeline writes to S3, you are on an experimental path.

Smart modules are the transformation mechanism, built with the Smart Module Development Kit (smdk) and distributed through the InfinyOn Cloud hub according to the README. The repository layout supports this: there is a smartmodule directory at the top level, a smartmodule-development-kit crate, and a smartmodule/regex-filter entry that the workspace explicitly excludes from the members list, which suggests it is built separately from the main workspace.

Client coverage is uneven and the README is honest about it. Rust, Python and JavaScript clients are listed under language-specific API docs. Go, Java and Elixir are grouped under "Community Maintained." That grouping is the thing to check against your stack. A community-maintained client is not the same commitment as a first-party one, and the README does not state a support policy for either category.

## Where Fluvio is the wrong choice

The release history is the clearest limitation. The most recent tagged release is v0.18.1 from 2025-07-04, with a dev tag from 2026-05-14. For a project whose README tells you to install the dev FVM because releases are being re-hosted, pinning a production cluster to a stable version means pinning to something published over a year before the last push. That is a real constraint, not a cosmetic one.

The second limitation is the experimental connector list. If your architecture depends on writing to S3, Redis or DuckDB, the README itself flags those as experimental builds, which tells you the API and the package format may move.

The third is platform. The README recommends WSL2 on Windows rather than claiming native support. If you cannot run Linux or WSL2, this is not the tool for you.

Finally, consider what you are replacing. If you only need durable, ordered log storage with consumer groups and you already have a Kafka cluster, Fluvio's connector and smart module layer is the part that would justify a migration, and the part you would be adopting on an experimental footing. If you need a full SQL-based stream processor with a large connector ecosystem, the Stateful DataFlow framework is a different programming model and a younger one.

## Fluvio compared with Kafka, Flink, NATS and Arroyo

The comparison people search for most is Fluvio against Kafka. The architectural difference is where transformation happens. Kafka is a log with client-side processing; you write a consumer, run it somewhere, and manage that deployment. Fluvio puts the transformation in the stream as a WebAssembly smart module and packages connectors as deployable objects with a development kit. That removes a moving part from your side, and adds one to the platform's side, since you now depend on the smart module runtime and the connector packages.

Against Flink, the split is state. Flink is a stateful stream processor with its own job graph, checkpointing and state backends. Fluvio's Stateful DataFlow framework is the counterpart here, and the README links to its own quickstart and architecture pages rather than folding it into the core docs. If you need exactly-once stateful computation with a mature operator ecosystem, Flink is the more established answer.

Against NATS, the difference is the data model. NATS is messaging and request-reply first, with JetStream adding persistence. Fluvio is topic and partition first, with connectors and transformations built around that. If your workload is service-to-service messaging, NATS is closer to the shape of the problem.

Against Arroyo, which is a SQL stream processing engine, the difference is the interface. Arroyo asks you to write SQL over streams. Fluvio asks you to write Rust or another supported client language, or a WebAssembly smart module. The choice is about which of those your team will maintain.

## Maintenance, licensing and upgrade cost

Fluvio is licensed under Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations when you redistribute. This is a description of the licence identifier, not legal advice; check the obligations against how you ship.

The repository is not archived, and the last push was on 2026-08-30. That is recent enough that the codebase is moving. But movement is not the same as a stable release cadence: the release list shows v0.18.1 tagged on 2025-07-04, a dev tag on 2026-05-14, and the README's temporary note about re-hosting the build and release. Upgrading therefore means tracking the dev channel or waiting for a tagged release that the README does not promise.

Upgrade cost also depends on which parts you touch. A deployment that only uses topics and a first-party client is the cheapest to move. One that ships custom connectors built with cdk, or smart modules built with smdk, carries those artifacts forward with each upgrade, and the README gives no compatibility contract for either kit. Budget for re-reading the connector and smart module docs at each version bump rather than assuming the package format holds.

## Conclusion

Adopt Fluvio if you want a Rust-native streaming engine with WASM transformations and declarative connectors, and you are comfortable reading the docs site rather than a single reference page. Do not adopt it if you need a long-term support release or a mature managed offering; the README itself notes the project is transitioning its build and release hosting, and the current install path requires FVM_VERSION=dev. Before committing, verify three things: that fluvio cluster start works on your target platform (the README points Windows users to WSL2), that the connectors you need are in the supported list rather than the experimental one, and which versions are actually published on the channel you intend to pin.

## FAQ

### How does Fluvio compare with Kafka?

The main difference is where transformation happens. Kafka is a log with client-side processing, while Fluvio applies wasm based stream processing through smart modules and deploys connectors as packaged objects. Fluvio also ships its own Stateful DataFlow framework for the processing layer.

### How does Fluvio compare with NATS?

Fluvio is built around topics and partitions with connectors that collect data into those topics, and the README describes it as a distributed data streaming engine. NATS is not covered in the README, so the repository does not document a direct comparison.

### How does Fluvio compare with Flink?

Fluvio pairs its streaming engine with the Stateful DataFlow framework, which the README links to its own quickstart and architecture pages. Flink is not discussed in the README, so no feature-by-feature comparison is documented there.

### How does Fluvio compare with Arroyo?

Arroyo is not mentioned anywhere in the README or the repository files, so the project does not document a comparison. What the README does describe is a Rust streaming engine with WebAssembly smart modules and a Stateful DataFlow framework.

### What are the alternatives to Fluvio?

The README does not list alternatives. It does describe Fluvio's own inbound connectors for http, webhook, mqtt and kafka, and outbound connectors for http, SQL and kafka, with DuckDB, Redis, S3 and Graphite as experimental builds.

## Sources

- [fluvio-community/fluvio on GitHub](https://github.com/fluvio-community/fluvio)
- [License: Apache-2.0](https://github.com/fluvio-community/fluvio/blob/master/LICENSE)
- [Project website](https://www.fluvio.io/)
- [README](https://github.com/fluvio-community/fluvio/blob/master/README.md)
- [Releases](https://github.com/fluvio-community/fluvio/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fluvio-community-fluvio