RisingWave : un moteur de streaming qui veut remplacer Kafka, Flink et la base de service
Plateforme de streaming d'événements pour l'IA agentique. Ingérez, transformez et diffusez en continu des flux d'événements en temps réel et à grande échelle.
En bref
- De quoi s’agit-il ?
- RisingWave se présente comme une plateforme de streaming d'événements pour l'IA agentique, capable d'ingérer, de transformer et de servir des flux en temps réel. Ce projet Rust, sous licence Apache-2.0, vise à condenser un pipeline complet en un seul système, mais son approche mérite un examen attentif.
- À qui s’adresse-t-il ?
- Adoptez RisingWave si vous gérez des flux d'événements pour des agents ou des applications temps réel et que vous voulez unifier ingestion, traitement et service dans un seul système SQL, sans maintenir Kafka, Flink et une base séparée. Ne l'adoptez pas si votre équipe dépend déjà d'un écosystème Kafka/Flink mature ou si vous avez besoin de fonctionnalités avancées de traitement de flux non couvertes par le SQL.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Rust, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un problème d'architecture, pas seulement de vitesse
Ce positionnement est séduisant sur le papier, mais il repose sur une promesse forte : que le SQL suffit à couvrir tous les besoins de transformation. Pour beaucoup d'usages, c'est vrai. Pour d'autres, notamment les traitements très spécifiques ou les algorithmes propriétaires, le SQL peut devenir une contrainte. Le projet assume ce choix, mais il faut le comprendre avant d'adopter.
Le mécanisme : des vues matérialisées incrémentales
Le cœur du système est le calcul incrémental. Quand des données arrivent, RisingWave ne recalcule pas tout à chaque requête. Il maintient des vues matérialisées qui se mettent à jour en continu, en ne recalculant que les résultats affectés par les changements en amont. Le README annonce une fraîcheur de bout en bout sous 100 ms. Ce mécanisme est classique pour les moteurs de streaming, mais il est ici central : tout repose sur cette idée de vues toujours à jour, sans recomputation complète. Les requêtes sont servies depuis un magasin de lignes interne, avec une latence annoncée de 10 à 20 ms p99. Ce chiffre est à prendre avec précaution, car il dépend du matériel, du volume et de la complexité des requêtes. Mais l'architecture est cohérente : l'ingestion, le calcul et le service sont unifiés sous une même interface SQL.
Ingestion et service : tout passe par SQL
RisingWave ingère depuis plusieurs types de sources : des webhooks HTTP, des changements de bases de données via CDC natif (PostgreSQL, MySQL), des flux Kafka, Pulsar, Kinesis, et des données historiques depuis S3 ou des entrepôts. Toutes ces sources sont unifiées sous la même interface SQL. Cela signifie qu'un agent IA peut interroger un flux Kafka comme une table SQL classique. Le service se fait via le protocole wire PostgreSQL, ce qui permet d'utiliser psql, JDBC et tout outil compatible Postgres. Pour les agents, le projet propose un serveur MCP, un CLI et des Skills, afin qu'ils puissent interagir sans intégration personnalisée. Cette approche est pragmatique : elle réduit la courbe d'apprentissage pour les équipes qui connaissent déjà SQL.
Stockage : le row store et Iceberg, deux usages distincts
Le stockage est divisé en deux couches. Le row store interne sert les requêtes à basse latence. Il est conçu pour le service en temps réel. En parallèle, RisingWave écrit dans des tables Apache Iceberg pour la conservation à long terme et les requêtes analytiques. Le projet héberge le catalogue REST Iceberg directement et gère la maintenance des tables : compaction, optimisation des petits fichiers, nettoyage des snapshots. Les requêtes Iceberg sont exécutées via Apache DataFusion, un moteur vectorisé. Ce choix est intéressant car Iceberg est un format ouvert, lisible par Spark, Trino ou DuckDB. Mais cela ajoute une complexité d'exploitation : il faut gérer deux systèmes de stockage, même si RisingWave les orchestre. Le README précise que le row store et Iceberg servent des objectifs différents : l'un pour la latence, l'autre pour la durabilité et l'analyse.
Coût et élasticité : l'object storage comme pari
Une décision de conception majeure est de stocker l'état interne, les tables et les vues matérialisées dans de l'object storage (S3 ou équivalent). Le README affirme que cela est environ 100 fois moins cher que la RAM. Cela permet un scaling élastique sans rééquilibrage des données et une récupération après panne en quelques secondes. Pour les workloads sensibles à la latence, un cache disque élastique peut épingler les données chaudes sur SSD ou EBS, maintenant la latence p99 à 10-20 ms. Ce pari est audacieux : l'object storage a des latences plus élevées que la RAM, mais le cache disque compense. Le compromis est clair : coût réduit contre complexité de gestion du cache. Il faut tester dans son propre environnement pour voir si les performances correspondent aux annonces.
Limites et cas où c'est le mauvais outil
RisingWave n'est pas adapté à tous les scénarios. Si votre équipe a déjà investi dans un écosystème Kafka/Flink avec des connecteurs personnalisés, le remplacer par un système unique peut être risqué. Le SQL, même étendu, ne couvre pas tous les besoins de traitement de flux : certains algorithmes de fenêtrage complexes ou des opérations d'état très spécifiques peuvent être difficiles à exprimer. De plus, le projet dépend fortement de l'object storage pour son modèle de coût : si vos volumes sont modestes, l'avantage est moins net. Enfin, la fraîcheur sous 100 ms et la latence 10-20 ms p99 sont des chiffres annoncés, pas des garanties. Dans un environnement avec des pics de charge, ces métriques peuvent se dégrader. Il faut donc valider avec des tests de charge représentatifs.
Alternatives : Kafka Streams ou un pipeline maison
La principale alternative est de conserver un pipeline classique : Debezium pour le CDC, Kafka pour le transport, Flink pour le calcul, et une base comme PostgreSQL ou ClickHouse pour le service. Cette approche est plus modulaire, chaque composant étant spécialisé. Kafka Streams, par exemple, permet un traitement de flux en Java/Scala, mais il ne fournit pas de service SQL natif. Là où RisingWave se distingue, c'est qu'il offre une interface SQL unifiée pour tout : ingestion, transformation, service. Si vous avez besoin de requêtes ad hoc sur des flux, RisingWave est plus direct. Si vous avez besoin de traitements très personnalisés ou si vous voulez garder le contrôle de chaque étape, un pipeline classique reste pertinent. Le choix dépend de votre besoin de simplicité contre votre besoin de flexibilité.
Coûts de maintenance et licence
Le projet est sous licence Apache-2.0, ce qui est permissif : vous pouvez l'utiliser, le modifier et le redistribuer sans restriction majeure, sous réserve de respecter les conditions de la licence. C'est un point positif pour l'adoption. En termes de maintenance, le projet est actif avec des versions récentes (v3.0.3 en août 2026). Mais la documentation mentionne la télémétrie : RisingWave collecte des statistiques d'utilisation anonymes via Scarf, avec possibilité de désactivation. Cela implique une vérification de la configuration si vous avez des exigences de confidentialité. Pour la maintenance, le projet gère automatiquement la compaction et le nettoyage des snapshots Iceberg, ce qui réduit la charge opérationnelle. Cependant, vous devez surveiller le cache disque et les performances de l'object storage. Le coût de mise à niveau est à évaluer : les versions majeures peuvent introduire des changements de comportement. Il est prudent de tester les mises à jour dans un environnement de staging avant de les déployer.
Conclusion éditoriale
Adoptez RisingWave si vous gérez des flux d'événements pour des agents ou des applications temps réel et que vous voulez unifier ingestion, traitement et service dans un seul système SQL, sans maintenir Kafka, Flink et une base séparée. Ne l'adoptez pas si votre équipe dépend déjà d'un écosystème Kafka/Flink mature ou si vous avez besoin de fonctionnalités avancées de traitement de flux non couvertes par le SQL. Avant de vous engager, vérifiez la compatibilité de vos sources (notamment le CDC natif pour PostgreSQL et MySQL), testez la latence annoncée de 10-20 ms p99 dans votre environnement, et évaluez le coût de l'object storage pour vos volumes de données. Le projet est actif, mais sa maturité dépend de votre cas d'usage précis.
Notes de la communauté