Rivet 3.0 ersetzt NATS durch S3 – Hersteller nennt 4,99 ms Cold Start

Rivet 3.0 ersetzt NATS durch S3 und läuft als eine zustandslose Binary

Rivet (YC W23) stellt im Rahmen eines Launch HN einen Orchestrator für KI-Agenten-Workloads vor. Er basiert auf dem Actor-Modell. Laut Hersteller bringt Version 3.0 eine neue Storage-Engine namens WarpDrive mit. S3 sei die einzige Abhängigkeit, Rivet laufe als eine zustandslose Binary, und NATS habe man durch S3 ersetzt.

Ein Actor ist in Rivet ein langlebiger Prozess mit In-Memory-Zustand und einer eigenen SQLite-Datenbank, die auf S3 liegt. Adressiert wird er über einen Key. Angelegt werden sollen Actors pro Agent, Session, Nutzer oder Mandant. Mehrere Actors teilen sich den Prozess eines Nodes, statt je eine Sandbox oder VM zu starten. Im Leerlauf hibernieren sie: Sie schreiben ihren Zustand weg und laden ihn bei der nächsten Anfrage wieder.

Rivet steht unter Apache-Lizenz. Nutzen lässt sich das Produkt über Rivet Cloud oder selbst gehostet, als Rust-Binary oder als Container. Als Alternative zu Cloudflare Durable Objects positioniert sich der Anbieter. Die dazugehörigen Vergleichsseiten sind Herstellerpositionierung und kein unabhängiger Vergleich.

4,99 ms Cold Start und 72 KB pro Actor: Was Rivet gemessen hat und gegen wen

Rivet nennt 4,99 ms p99 für den Cold Start, 72 KB RAM pro Actor, 1,07 ms p99 für dauerhafte Schreibzugriffe und 1,36 ms p99 für Lesezugriffe. Der Speicher sei rund 10,4-mal günstiger als replizierter SSD-Speicher. Diese Zahl hängt laut Material von Preis- und Lastannahmen ab, die nicht genannt werden.

Der Cold Start umfasst das Scheduling des Actors, das Laden des Zustands und die Antwort auf die erste Anfrage. Image-Pull und VM-Boot entfallen und fließen deshalb nicht ein.

Die 72 KB (genauer 72,4 KB) bilden den Resident Memory, den ein laufender Actor zusätzlich belegt. Gemessen hat Rivet das im September 2026 mit dem Rust-SDK. Der Vergleichswert für E2B von 512 MiB pro Sandbox ist dagegen der dokumentierte Standardwert. Er stammt aus der E2B-Dokumentation und einem Drittbenchmark und wurde nicht von Rivet gemessen. Ob allokierter und tatsächlich belegter Speicher sich vergleichen lassen, nennt das Material selbst als offene Frage.

Für den Vergleich mit Cloudflare Durable Objects veröffentlicht Rivet einen Benchmark. Er läuft auf Release 3.0.3, auf drei Azure-VMs mit lokalem NVMe in drei Availability Zones. Die Cloudflare-Seite wird aus derselben Azure-Region angesteuert. Der Lauf fand am 5. November 2026 statt. Rohdaten, Report und Skripte liegen im Repo. Die Basislinien unterscheiden sich: 0,45 ms bei Rivet (Client zu Actor), 11 ms bei Cloudflare (Worker zu Durable Object). Bei den Gruppen Create und Write wird der Median von jedem Sample abgezogen. Der Anbieter nennt den Vergleich „apples to apples“.

Unabhängige Bestätigung fehlt, und zwei Angaben passen nicht zusammen

Unabhängige Bestätigungen und Praxisberichte liegen bislang nicht vor. Außerdem passen zwei Angaben nicht ohne Weiteres zusammen. Für Pi 1.0 nennt Rivet 0,82 MB RAM pro Session, etwa das Elffache der 72 KB. Das Material erklärt den Unterschied nicht. Vermutlich handelt es sich um unterschiedliche Messgrößen, etwa einen leeren Actor im Vergleich zu einer realen Agenten-Session.

Eine Drittbeschreibung von RepoCloud nennt für die Engine (v2.3) noch RocksDB, PostgreSQL und NATS. Sie wirkt älter, belegt ist das aber nicht. Der Rivet-Blog spricht außerdem nur von einer „3.0 Preview“, während der Benchmark Release 3.0.3 verwendet.

Entscheider vor einer Plattformwahl können die Zahlen mit dem Benchmark-Repo selbst nachmessen.