Why Ursula

Ursula is a durable, replayable stream layer for application state. Each document, session, task, room, or agent run gets its own ordered stream that supports recovery, replay, live updates, snapshots, and eventual expiry.

You can think of it as a per-entity durable log runtime. It is purpose-built for this pattern, not a general-purpose event backbone or stream storage primitive.

One stream per entity

Most event systems multiplex many entities into shared channels. Consumers reconstruct per-entity state downstream. Ursula inverts this: each entity owns its own durable timeline. Writers append directly to that stream, and readers resume from its offsets. Buckets group related streams under one namespace.

This gives you:

• Replayable recovery. When a worker, sandbox, or agent restarts, replay the entity's log and continue.
• Live tails with simple clients. Watch progress over HTTP with catch-up reads, long-poll, or SSE.
• Built-in lifecycle. Snapshots, bootstrap, and TTL fit the same timeline model instead of becoming separate infrastructure.

Tradeoffs

Ursula makes one durable timeline per entity cheap and ergonomic. In exchange, it is not trying to be the most general abstraction for cross-system event distribution or arbitrary stream processing pipelines.

That tradeoff is intentional: the simpler the per-entity model, the easier it is to recover, inspect, and operate long-running application state.

For how the write path achieves low latency and strong durability without S3 on the hot path, see Architecture. For concrete latency and cost numbers, see Competitive comparison.

Next steps

• Quick start: create a stream and append data with curl
• Streams: the core stream abstraction and lifecycle
• Architecture: how the cluster works
• API overview: the HTTP routes and request patterns