Plural Telemetry
Manifesto:why observability should cost less than the thing it observes

Observability should be cheap and easy.

Plural Telemetry is a Rust reimplementation of Prometheus, Loki and Tempo, built directly on object storage with SlateDB. You run two kinds of pods instead of ten, keep your Grafana dashboards, and the only stateful dependency is a bucket.

Install the operatorHow it works

Apache 2.0 · Kubernetes 1.28+ · sponsored byPlural

What's inside

Plural Telemetry is three databases that share one storage engine, one sharding protocol, and one Kubernetes operator. Each one speaks the wire protocols and query language of the system it replaces, so agents, dashboards and alerts keep working when you switch.

MetricsMimir

Prometheus-compatible TSDB with remote write and OTLP.

Read the docs
LogsLoki

Loki-compatible log store with LogQL, OTLP and _bulk ingest.

Read the docs
TracesTempo

Tempo-compatible trace store with TraceQL and OTLP.

Read the docs
Fig. 1 — Three databases, one storage engine
remote write · OTLPLoki push · OTLP · _bulkOTLP · Zipkin · JaegerMetricsPrometheus · Mimir-compatiblewriters ×Nreaders ×NLogsLoki-compatiblewriters ×Nreaders ×NTracesTempo-compatiblewriters ×Nreaders ×NSlateDBembedded LSM · one database per storage shard · single writer, many readersWALgroup commitmemtablein-memoryL0 SSTsflushedsorted runscompactedmanifestwriter fencingblock cacheFoyer · RAM + NVMeObject storageThe only stateful dependency: 11 nines of durability, no replicated disks, no cross-AZ replication traffic.S3GCSAzure BlobMinIO
Writes are batched into a WAL and memtable, flushed as SSTs to object storage, and compacted in the background. Each storage shard is its own SlateDB database owned by exactly one writer.

Built on SlateDB

SlateDB is an embedded LSM-tree key/value engine that writes its WAL and SSTs straight to object storage. It gives each Plural Telemetry database:

  • Zero-disk durability. Data is durable once it lands in S3, GCS or Azure Blob. Local NVMe is a disposable cache, not a replica.
  • Single writer, many readers. A fenced manifest guarantees one writer per database. Readers open the same data read-only and scale independently.
  • Tunable cost and latency. Batched WAL uploads trade per-request API cost against durability latency. Writes can acknowledge as applied, written or durable.
  • Background compaction. Sorted runs are merged off the hot path, so readers see a small number of large, cacheable objects.

SlateDB is single-writer by design. Plural Telemetry adds the missing piece for observability workloads, which is many writers: epoch-based sharding routes every record to one of up to 4,096 storage shards, and each shard is its own SlateDB database.

By the numbers

Differential fuzzing runs every product against its peer on the same data and queries. These figures come from the published runs. Methodology and per-run history are on each database's Benchmarks page.

5×
faster median trace query vs Tempo
0.63×
median per-query latency vs Loki
1/18
of Mimir's CPU for the same workload
0
replicated disks, rings, or ZooKeeper

Productionization

On top of SlateDB, Plural Telemetry adds what a real observability backend needs:

  1. Sharding. Multiple writers, coordinated by Kubernetes Lease objects and a ShardMap custom resource. No etcd, ZooKeeper or memberlist to run.
  2. Multi-tenancy. Every route is namespaced (/read/ns/{namespace}/…), and tenant isolation is encoded in storage keys.
  3. Authentication. Basic auth per namespace through NamespaceAuthentication resources, or JWKS-verified RS256 JWTs.
  4. Oracle testing. Each database is continuously diffed against Prometheus, Mimir, Loki or Tempo on the same inputs.
Where to next

Start with the installation overview, read the manifesto for the why, or jump straight into a database with the switcher in the top left.