One stream per entity
Most event systems multiplex many entities into shared channels. Consumers reconstruct per-entity state downstream. Snakream 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
Snakream 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