s2-lite

s2-lite is designed to run as a single instance, making self-hosting straightforward. See the README for more on its internals and quickstart for running it via the s2 CLI. Docker images are available. You can also use the Helm chart for deploying to Kubernetes. The SDKs and CLI can connect to s2-lite by overriding the default endpoints. See SDK: Endpoints and CLI: Configuration for details.

Even if you plan to exclusively use the cloud service, s2-lite is useful as an S2 emulator for integration tests and CI/CD pipelines. This way your tests run against a real S2 instance without needing network access or credentials.

Cloud service comparison

Start with what’s the same. Both s2.dev and s2-lite implement the core S2 API — the OpenAPI spec is in fact generated from s2-lite — and the same SDKs, CLI, and Studio work with either. For s2-lite, this comparison assumes object storage mode, although local disk and in-memory are also supported.

	s2.dev	s2-lite
Architecture	Elastic — components scale out, and streams migrate to balance load	Single node that scales vertically, which can take you surprisingly far
Storage engine	Purpose-built: low-latency WAL with batched segments on object storage	SlateDB on object storage
Append latency	Within 40 ms on `express` and 400 ms on `standard` storage class	Your bucket’s PUT latency plus tunable flush interval; typically few hundred ms
Durability	Multi-AZ before every ack, even on `express`	Inherits your bucket’s durability, typically multi-AZ in the cloud
Read fan-out	Elastic read-through caching — effectively a CDN for streams	Bounded by one node — layer your own caching on top for broadcast scale
Security	SOC 2, HIPAA, and GDPR compliant; private networking and dedicated cells available	Your perimeter end-to-end — data touches only infrastructure you control
Operations	None — serverless and scale-to-zero, with usage-based pricing	Single binary and a bucket: yours to provision, monitor, and scale
Auth	Granular access control	Gate with your own auth layer — access token API support is planned
Open source	Managed service; MIT-licensed API layer and ecosystem projects	MIT-licensed server implementation
Maturity	GA with a 99.99% availability SLO	Newer, though shares code with the cloud service, and builds on top of SlateDB

Latency is mostly about proximity. With the cloud service it depends on how close your workload runs to your basin’s location; with s2-lite you control placement, so colocating it and its bucket with your workload can win where S2 does not have a nearby location yet. At a comparable distance, the express storage class delivers multi-AZ durability with tens-of-milliseconds acks — a combination that is hard to match when flushing to a single bucket. Like the cloud service, s2-lite also pipelines appends, so throughput holds up well even against high-latency object storage, and s2 bench makes it easy to measure your own numbers. Cost follows from operations. The cloud service is purely usage-based and scales to zero — there is no instance to keep warm, which for spiky or modest workloads usually makes it cheaper too — and there are no knobs to think about: storage class is the only latency lever, with durability never in question. With s2-lite you pay for the node and the bucket, and the flush interval ties latency to cost: flushing more aggressively acknowledges appends sooner but increases billable object storage requests. Reach for the cloud service when you want a production stream store without operating one: elasticity, high fan-out, the lowest acknowledgment latencies, granular access control. Reach for s2-lite when self-hosting is the point — keeping data in your own bucket and network, running where the cloud service does not (an edge site, an air-gapped environment, a location S2 does not offer yet), or as a zero-dependency emulator in dev and CI. Whichever you start with, the shared API means your application can switch with an endpoint override rather than a rewrite.

Init file

s2-lite can pre-create basins and streams at startup from a JSON spec file using the same format used by s2 apply.

s2 lite --init-file init.json

Or set the environment variable:

S2LITE_INIT_FILE=init.json s2 lite

The spec is applied with create-or-reconfigure semantics. Resources that already exist are reconfigured to match the spec, and only the fields present in the spec are updated. Example init.json:

{
  "$schema": "https://raw.githubusercontent.com/s2-streamstore/s2/main/cli/schema.json",
  "basins": [
    {
      "name": "my-basin",
      "config": {
        "create_stream_on_append": true
      },
      "streams": [
        { "name": "events" }
      ]
    }
  ]
}

See CLI: Apply for the full spec file format reference.

Use Cases

Open Source

Cloud service comparison

Init file

​Cloud service comparison

​Init file

Cloud service comparison

Init file