The fast, tiny
time-series database.

A full database in one small binary.

Everything below ships in the same binary. The query language is never paywalled — high availability is the only Pro feature.

Measured, not marketed.

Every claim above is a measurement below. Anzaran, QuestDB 9.4.3, and VictoriaMetrics 1.136.0 ran side by side on one AWS c7i.2xlarge, each capped at 2 CPUs and 4 GB RAM, ingesting the same 50 million points across one million series and answering identical randomized queries. Forty-eight cross-engine correctness checks per competitor had to pass before any latency counted — 48/48 vs both, each pair carrying 8 deliberate, logged non-checks where the two query languages have no faithful equivalent.

Per-workload latency — 1M series (cold p50, ms)

Anzaran is fastest on all 8 shapes — every cell, both competitors.

Throughput under concurrency — 1M series

Anzaran serves 4,251 queries per second at 8 clients — ~26× QuestDB and ~1,100× VictoriaMetrics — with cold p50 of 2 ms or less at every concurrency level. QuestDB's p50 degrades ~98× from 1 to 32 clients; VictoriaMetrics collapses to 3.7 QPS with multi-second latencies at this cardinality. Anzaran deliberately admission-controls concurrent metric-wide scans (two at a time; the rest receive an immediate retryable 429 rather than queueing) — that back-pressure is included in the QPS shown.

Ingest — 1M series (zero errors, all engines)

Ack semantics differ, and it matters: Anzaran's acknowledgment is durable — every acked point is fsync'd to the write-ahead log before the 200. QuestDB acks with relaxed commit lag; VictoriaMetrics acks from an in-memory buffer before any durable persistence. Anzaran posts the fastest low-cardinality ingest of the three while giving the strongest guarantee.

10 million series — where the others stop

Anzaran solo — at 10M series under the same 4 GB cap, neither competitor completes the workload at all (a measured finding, not a jab: their ingest never finished inside the harness limit). Counts are answered from maintained indexes, verified exact in-run by 23 closed-form count oracles and 6 value-sum oracles at 10M; the 0.2 ms sealed-data row is served entirely from Anzaran's sorted-runs index and is labeled separately for exactly that reason. A store carried forward from an older release serves those two rows at walk speed until that index has been rebuilt. Acked writes survive restarts — the contract is pinned by an automated ingest→restart→exact-count chaos test in the release gate.

All tables: measured Aug 2026 on AWS c7i.2xlarge (8 vCPU / 16 GB), each engine cgroup-capped at 2 CPU / 4 GB, official competitor images, identical line-protocol data, randomized cache-defeating query windows. Honest caveats: one shared machine per run; comparisons are relative; single-digit-ms deltas near the HTTP floor are transport, not engine.

Small footprint, small bill.

The cheapest infrastructure is the infrastructure you don't need. Anzaran's resource profile is designed to keep your cloud bill boring.

^† The memory row is the 2026-07 two-engine run on macOS Docker (483,732 points, 2 CPU / 4 GB each) and reports memory at the end of that run, not memory at rest. VictoriaMetrics was not in it, and Anzaran's S3 cold-tier sidecar, which adds 97 MiB when you run one, is not counted. Every other row is the 1M-series AWS run.

Cold data tiers to S3 object storage (~$0.023/GB-month) instead of growing block storage (~$0.08/GB-month gp3) — and S3 tiering is free on every Anzaran tier. Instance rows are illustrative x86_64 on-demand list prices, AWS us-east-1 (Anzaran targets x86_64 today; ARM builds are planned); your workload will vary.

Simple, public pricing.

Every tier runs the same binary with the full ZQL language. You pay for high availability and scale, not for features held hostage.

Get it, run it, talk to us.

Anzaran is one Docker command away, and the people who build it are one email away.

# Start a single node with a persistent data volume
$ docker run -d -p 8080:8080 -v anzaran-data:/data -e TSDB_WAL_DIR=/data ghcr.io/samisoftb/zigtsdb:latest

# Write a point (InfluxDB-style line protocol)
$ curl -X POST localhost:8080/ingest \
    -d "cpu_usage,host=web-1 value=75.5 1704067200000000000"

# Query it with ZQL
$ curl "localhost:8080/query?zql=SELECT avg(value) FROM cpu_usage"