Ursulav0.1.4

Why Ursula

What Ursula keeps

A new generation of event streams lives outside the broker network. Document editors, agents, and durable workflows need timelines that browsers, mobile apps, and serverless functions can read, write, and tail over the public internet. That asks for HTTP-native, distributed, S3-backed infrastructure, not the SDK-locked, single-network shape Kafka-style brokers were built for.

The Durable Streams Protocol nails that wire format, but its reference server is a single process: a node loss is data loss. The other servers we evaluated each force you to give up one of four things this primitive deserves to keep:

  • Open-source self-hosting.
  • Low write latency (sub-50 ms appends, no batching window required).
  • Plain S3 economics (cold tier on standard S3, no S3 Express tier, no per-GB SaaS markup).
  • Quorum-replicated durability (acknowledged writes survive a single-node failure).

Ursula keeps all four. For the head-to-head numbers, see How Ursula compares.

One timeline per entity

Most event systems multiplex many entities into shared channels and rebuild per-entity state downstream. Ursula inverts that: each document, session, task, room, or agent run gets its own durable timeline. Writers append directly to it; readers resume from its offsets.

Treat it as a per-entity durable log runtime, purpose-built for that pattern rather than a general event backbone.

What you get from one stream per entity

  • Replayable recovery. When a worker, sandbox, or agent restarts, replay its log and continue.
  • Live tails with simple clients. Catch-up reads, long-poll, or SSE, all over plain HTTP.
  • Lifecycle in the same primitive. Snapshots, bootstrap, and TTL ride the timeline instead of being separate infrastructure.

The tradeoff

Ursula makes one timeline per entity cheap. In exchange, it isn't the most general primitive for cross-system event distribution or arbitrary stream processing. Keeping the per-entity model simple is what makes recovery, inspection, and operation tractable for long-running application state.

For latency and durability numbers, see Architecture and Competitive comparison.