S2 treats a stream the way S3 treats an object

Nobody provisions a cluster to store a file.

You put bytes in a bucket. The cloud keeps them durable, replicated, and retrievable, and the bill reflects what you actually stored. It is easy to forget how strange that once seemed. Object storage turned "keeping data safe" from an infrastructure project into an API call, and an entire generation of software, from data lakes to backup systems to the training pipelines behind modern AI, was built on the assumption that storage is simply there.

Streams never got that treatment. If an application needs a durable, ordered, real-time log of events today, somebody on the team ends up operating a streaming system: a Kafka cluster with brokers to size and partitions to count, or a managed service with shards to provision and limits to design around. The stream, one of the most useful abstractions in software, still arrives shaped like a cluster.

S2 exists to close that gap. The company calls itself the Stream Store, and the name is a precise statement of intent: a serverless API for durable, real-time streams, unlimited in number and in storage, priced by usage. You create streams the way you create objects in a bucket, in whatever quantity the design calls for, and the platform handles durability and scale. S2's cloud service reached general availability in February 2026, backed by a $3.85M seed round led by Accel, with participation from Y Combinator and angels including Theo Browne. Total funding stands at $5.5M.

The primitive that never shipped

The case for S2 starts with an observation about why streaming infrastructure feels heavy: the systems we use were designed around scarce resources.

A Kafka partition is not a lightweight thing. It maps to files on broker disks, participates in replication, and consumes cluster resources whether or not data is flowing. Teams plan partition counts ahead of time and change them reluctantly. Managed alternatives lighten the operations but keep the shape, with shards or partitions as the unit you buy and throughput ceilings you architect around.

That scarcity warps designs. What many systems naturally want is a large number of small, independent, ordered logs: one per user, one per device, one per document, one per workflow run. Because partitions are expensive, engineers instead multiplex thousands of logical streams onto a handful of physical ones, then rebuild the separation in application code with keys, filters, and consumer-side bookkeeping. The infrastructure's constraints leak all the way up into the data model.

S2's founding argument is that this scarcity is an artifact, not a law. Object storage already demonstrated that a cloud service can offer effectively unlimited durable resources with usage-based pricing. Build a streaming API directly on that foundation and the stream can become what the object became: a primitive you allocate freely and stop thinking about.

Basins, streams, and records

The product's vocabulary mirrors object storage deliberately. A basin is the namespace, playing the role a bucket plays for objects. Inside a basin live streams, and into streams go records, appended at the tail and read in order.

The API surface is small but complete. Appends are durable when acknowledged, and readers can tail a stream in real time or replay it from any earlier position, with retention configurable per stream. Sessions keep a connection open for pipelined writes or continuous reads, so high-throughput producers and tailing consumers are first-class rather than a pattern you fake with polling. Concurrency control on appends supports coordinated writers, which matters once many processes contend for the same ordered log.

S2 ships a gRPC API, a Rust SDK, and a CLI, with SDKs that follow the same hierarchical pattern: authenticate a client, open a basin, operate on streams. There is no cluster to create first and no capacity decision anywhere in the flow. The count of streams in a basin can be one or one million, and the platform's answer is the same.

Everything sits directly on object storage, which is where the durability story comes from. Rather than treating S3 as a cold archive behind a disk-based hot tier, S2 is architected so the object store is the storage layer, inheriting its durability and scale.

Latency is a dial on each stream

The reflexive objection to building streams on object storage is latency, and S2's answer is one of its more interesting design decisions: latency is configurable per stream, through storage classes.

The Standard class is backed by S3 Standard and delivers end-to-end p99 latencies under 500 milliseconds. That is comfortably real time for feeds, logs, analytics ingestion, and most event-driven workloads. The Express class is backed by a quorum of three S3 Express One Zone buckets and brings end-to-end p99 latency under 50 milliseconds, fast enough for interactive applications where a user or an agent is waiting on the write. Both classes support throughput of hundreds of megabytes per second on a single stream.

The interesting part is that the cost and latency trade-off moves out of the architecture and into a per-stream setting. The same API, the same data model, and the same code serve a cheap archival firehose and a latency-sensitive session log; you choose per stream instead of standing up different systems for each.

Priced like storage, not like a cluster

S2's pricing follows the object storage playbook: pure usage-based billing across retained data, writes, reads, and API operations, with no idle cluster charging you for the hours nothing happened.

Some of the metering details show how seriously the team takes the high-volume case. For appends, the per-operation charge is waived for subsequent requests within the same minute on the same connection, so a pipelined producer pays for throughput rather than for chattiness. Long-lived sessions are metered at one stream operation per minute. These are the kinds of decisions you make when you expect customers to run millions of small streams and want the economics to stay sane at that scale.

The contrast with cluster-shaped pricing is the strategic wedge. A team that needs ten durable streams today should not have to buy, size, and babysit infrastructure designed for ten thousand. And a team that suddenly needs ten million streams should not have to redesign anything at all.

A stream per agent session

Unlimited cheap streams sounded like a nice-to-have until AI agents arrived and made it a requirement.

An agent session is naturally an event log. Every tool call, model response, user interruption, and state change is an ordered sequence of events that the application wants to persist durably, follow in real time, and replay later, whether to resume an interrupted session, audit what the agent did, or reconstruct its memory. Event sourcing, an architecture that was often judged too heavy for ordinary web apps, is close to the obvious design for agents.

The awkward part is cardinality. A stream per agent session means the number of streams grows with usage, not with architecture diagrams. Sessions appear by the thousands, live for minutes or for months, and each one needs its own durable, ordered log. That is a terrible fit for a world of pre-provisioned partitions and a natural fit for a stream store, and S2 leans into the pattern explicitly, pitching a stream per session as the way agent builders get memory, state, and auditability without managing infrastructure.

The usage suggests the fit is real. By general availability, S2 reported customers creating millions of durable streams and pushing terabytes of data every week.

Built by someone who ran these systems

Founder and CEO Shikhar Bhushan spent his career on exactly the infrastructure S2 is trying to replace. He was an engineer at Confluent, the company built around Kafka, and later a senior staff engineer at Etsy, where he led the build-out of a streaming hydration system that powers search indexing and other streaming ingestion at the company, before leading its next-generation retrieval work. Stints at Facebook, Bloomberg, and Heap fill out a resume that reads like a tour of large-scale data systems.

That background shapes the product's temperament. S2 is a bet, made by someone who has operated partitioned logs in production, that the operating model everyone tolerates is the part worth removing.

An ecosystem forming at the edges

A primitive is only useful if the rest of the stack can reach it, and the early integrations sketch how S2 expects to be used.

Bytewax, the Python stream processing framework, ships a connector for S2, and the Bento stream processor can consume S2 streams as inputs and write results back out to other streams. The pattern in both cases is the same: S2 holds the durable streams, processors do the computation, and neither side needs to run a broker. For teams already deep in Kafka's or Kinesis's low-level APIs, S2 positions itself as a direct replacement for the storage layer underneath.

None of this makes S2 a drop-in Kafka for every workload today, and the company does not claim it is. What it claims is narrower and sharper: the durable stream itself, as a resource, should work like cloud storage. Two decades of software got built on buckets and objects once that abstraction existed. S2 has its seed round, its general availability, and millions of streams a week arguing that the stream is next.