RisingWave: Event-Streaming-Plattform für agentische KI in Rust
Event-Streaming-Plattform für Agenten-KI. Kontinuierliche Aufnahme, Transformation und Bereitstellung von Ereignisströmen in Echtzeit und im großen Maßstab.
Auf einen Blick
- Was ist das?
- Eine Ein-System-Alternative zur Kette aus Debezium, Kafka, Flink und bereitstellender Datenbank, mit Iceberg-Speicherung und SQL-Bereitstellung.
- Für wen ist es gedacht?
- Die zentrale Behauptung des README ist, dass ein System vier Komponenten ersetzen kann. Die genannten Latenz- und Kostenzahlen werden ohne veröffentlichte Methodik angegeben, und Benchmark- und Fallstudienseiten liegen außerhalb des Repositorys.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein System ersetzt vier Komponenten
RisingWave ist eine Event-Streaming-Plattform für agentische KI-Workloads. Das Repository beschreibt, dass das System kontinuierlich Daten aus Datenbanken, Event-Streams und Webhooks aufnimmt, diese inkrementell verarbeitet und frische Ergebnisse mit geringer Latenz bereitstellt. Das erklärte Ziel ist es, den traditionellen Event-Streaming-Stack, den das README als Debezium für Change Data Capture, Kafka für Transport, Flink für Verarbeitung und eine Datenbank für die Bereitstellung benennt, durch ein einziges System zu ersetzen. Das Projekt ist in Rust geschrieben und unter der Apache License 2.0 veröffentlicht. Das README verlinkt auf separate Benchmark- und Fallstudienseiten, aber das Repository selbst veröffentlicht diese Zahlen nicht.
Das Latenzproblem, das das README adressiert
Das README begründet die Motivation damit, dass Agenten und Echtzeitanwendungen Daten benötigen, die immer frisch und mit geringer Latenz abfragbar sind. Der herkömmliche Ansatz verkettet Debezium, Kafka, Flink und eine bereitstellende Datenbank, wobei jeder Hop Latenz hinzufügt und jedes System betrieblichen Overhead erzeugt. RisingWave wird als Abdeckung aller vier Ebenen dargestellt: Aufnahme, Verarbeitung, Bereitstellung und Speicherung. Die Frische- und Latenzwerte erscheinen im README als Produktbehauptungen: End-to-End-Frische unter 100 Millisekunden und p99-Bereitstellungslatenz von 10 bis 20 Millisekunden. Eine Benchmark-Methodik oder unabhängige Verifikation begleitet diese Behauptungen im Repository nicht.
Aufnahme aus vier Quellkategorien
Das README listet vier Quellkategorien auf. Webhooks übernehmen die HTTP-basierte Ereignisaufnahme aus SaaS-Anwendungen und externen Systemen. Datenbankänderungen kommen über natives Change Data Capture von PostgreSQL und MySQL durch Lesen der Transaktionslogs. Event-Streams stammen von Kafka, Pulsar, Kinesis und anderen Message-Brokern. Historische Daten werden durch Batch-Aufnahme aus S3, Data Warehouses und anderen Speichersystemen abgedeckt. Alle Quellen sind unter derselben SQL-Schnittstelle vereinheitlicht, und Streams und Tabellen können frei verknüpft werden. Der Schnellstart erfolgt über einen einzigen Shell-Befehl, der im README als curl -L https://risingwave.com/sh | sh angegeben ist; Docker, Kubernetes und andere Optionen sind im externen Schnellstartleitfaden dokumentiert.
Inkrementelle Verarbeitung und der bereitstellende Row Store
Die Verarbeitung wird als inkrementelle Berechnung beschrieben. Wenn sich Upstream-Daten ändern, werden nur die betroffenen Ergebnisse neu berechnet, sodass materialisierte Sichten ohne vollständige Neuberechnung bei jeder Abfrage aktuell bleiben. Abfrageergebnisse werden in einem internen Row Store gehalten und mit Standard-SQL bei einer p99-Latenz von 10 bis 20 Millisekunden bereitgestellt. Das README nennt kein Polling, kein Cache-Warming und kein TTL-Management als Eigenschaften dieser Bereitstellungsebene. Das Repository enthält keine Benchmark-Methodik oder unabhängige Verifikation für die Latenzwerte, daher sollten diese Zahlen als eigene Behauptungen des Projekts gelesen werden.
Apache Iceberg als dauerhafte Speicherebene
Für langfristige Aufbewahrung und analytischen Zugriff schreibt RisingWave in Apache-Iceberg-Tabellen. Laut README hostet es den Iceberg-REST-Katalog direkt und übernimmt Tabellenwartung, einschließlich Kompaktierung, Optimierung kleiner Dateien und Snapshot-Bereinigung, ohne externe Werkzeuge. Iceberg-Abfragen werden über Apache DataFusion ausgeführt, das als vektorisierte Abfrage-Engine beschrieben wird. Da Iceberg ein offenes Format ist, sind die Daten auch mit Spark, Trino, DuckDB und anderen Engines lesbar. Row Store und Iceberg-Ebene dienen unterschiedlichen Zwecken: der Row Store für die Bereitstellung mit geringer Latenz, Iceberg für dauerhafte Speicherung im offenen Format und analytische Abfragen. RisingWave verwaltet beide.
Designentscheidungen: Objektspeicher, Postgres-Protokoll und Agentenwerkzeuge
Das README nennt drei Designentscheidungen. Für Kosteneffizienz werden interner Zustand, Tabellen und materialisierte Sichten in Objektspeicher wie S3 gelegt. Das README sagt, dies sei etwa 100-mal billiger als RAM und ermögliche elastische Skalierung ohne Daten-Rebalancing sowie Fehlerbehebung in Sekunden. Ein optionaler elastischer Disk-Cache hält heiße Daten auf lokalen SSDs oder EBS für latenzempfindliche Workloads, und das README gibt an, dass die p99-Abfragelatenz bei 10 bis 20 Millisekunden bleibt. Für Kompatibilität verbindet sich RisingWave über das PostgreSQL-Wire-Protokoll und funktioniert mit psql, JDBC und Postgres-kompatiblen Werkzeugen. Für Agenten erwähnt das README einen MCP-Server, eine CLI und Skills, damit Agenten das System ohne benutzerdefinierte Integration abfragen und bedienen können. Die Entscheidung für Offenheit dreht sich um die native Apache-Iceberg-Integration: kontinuierliche Stream-Aufnahme, direkte Lesezugriffe über DataFusion und automatisierte Tabellenwartung.
Bereitstellung, Telemetrie und Lizenz
Als Bereitstellungsoptionen werden der verwaltete Dienst RisingWave Cloud sowie selbst gehostete Pfade über Docker Compose, Kubernetes mit Helm und Kubernetes mit dem RisingWave Operator genannt. Das README verweist für Details auf die Dokumentationsseite; das Repository selbst enthält diese Bereitstellungsmanifeste nicht. Die Telemetrie nutzt Scarf für anonymisierte Installationsanalysen sowie anonyme Nutzungsstatistiken; beide können abgewählt werden, Details finden sich in der Telemetriedokumentation. Das Projekt ist unter der Apache License 2.0 lizenziert. Die Lizenz gewährt eine unbefristete, weltweite, nicht ausschließliche, kostenlose, lizenzgebührenfreie, unwiderrufliche Urheberrechtslizenz zur Vervielfältigung, Erstellung abgeleiteter Werke, öffentlichen Darstellung und Aufführung, Unterlizenzierung und Verbreitung des Werks sowie eine entsprechende Patentlizenz. Der bereitgestellte Lizenzauszug macht keine Aussagen zu Sicherheitslage, Support oder Gewährleistung; diese Themen fallen nicht in den Umfang des Auszugs.
Redaktionelles Fazit
Die zentrale Behauptung des README ist, dass ein System vier Komponenten ersetzen kann. Die genannten Latenz- und Kostenzahlen werden ohne veröffentlichte Methodik angegeben, und Benchmark- und Fallstudienseiten liegen außerhalb des Repositorys. Das Projekt ist unter Apache 2.0 lizenziert, in Rust geschrieben, und die Repository-Metadaten verzeichnen 9.217 Sterne, 810 Forks und 1.593 offene Issues.
Community-Notizen