> ## Documentation Index
> Fetch the complete documentation index at: https://opendata.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Timeseries

> A Prometheus-compatible metrics database on object storage.

OpenData Timeseries is an MIT-licensed, Prometheus-compatible metrics database built on
[SlateDB](https://slatedb.io) and object storage. It speaks PromQL, scrapes
Prometheus targets, accepts Prometheus remote write and OTLP metrics, and works
out of the box with Grafana. It brings the object-store-native operating model,
ie. stateless compute nodes with object storage as the only durable layer, to the
Prometheus and Grafana ecosystem.

## What it's good at

* **Drop-in Prometheus and Grafana.** PromQL, scraping, remote write, and OTLP
  ingest, so your existing dashboards and alerts keep working.
* **High-cardinality ingestion.** Millions of active series on a single stateless
  writer, scaled by scaling the writer up.
* **Operational simplicity.** All you need for high-scale metrics is one writer, zero or more readers, and an object store bucket.
* **Cheap retention.** Local NVMe keeps weeks of recent data warm, while cold
  data lives on object storage at a large discount to disk-resident storage.

## Why Timeseries

Running Prometheus-compatible systems at scale has meant running an
unforgiving distributed storage system: quorum replication across stateful
nodes, shard management, and rebalancing when nodes fail or scale. Thus, whether you self-host
these systems or pay someone to manage them for you, they can get expensive very fast.

However, once object storage is the only durable layer and local disks are demoted to caches, most of
the complicated distributed database machinery disappears and the operational cost drops substantially.
This is what Opendata Timeseries delivers.

Because there is no replicated, partitioned state to babysit, you can realistically
run Timeseries yourself and capture the cost gap against managed services. See the
[benchmarks](/timeseries/benchmarks) for ingestion throughput, query latency, and
a cost comparison against managed Prometheus offerings.

## Tradeoffs

* **Cold reads pay object-store round trips.** A query for data that isn't cached
  locally is slower than the same query against a disk-resident system. SlateDB's
  block cache keeps recent and frequently read data warm, which covers most
  alerting and dashboard queries.
* **Higher end-to-end write latency.** Batching writes into immutable objects
  adds a few seconds before fresh data is queryable. Given scrape intervals are
  already on the order of a minute, that delay is rarely noticeable for
  observability.
  where the most optimization work is happening today.

## Explore Timeseries

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/timeseries/quickstart">
    Install Timeseries and query your first metrics in under five minutes
  </Card>

  <Card title="API Reference" icon="code" href="/api-reference/instant-query">
    Browse the Prometheus-compatible query and write API
  </Card>

  <Card title="Storage Design" icon="hard-drive" href="/timeseries/storage-design">
    How Timeseries organizes data in time buckets on SlateDB
  </Card>

  <Card title="Getting to Production" icon="server" href="/timeseries/production">
    Deploy, monitor, and secure Timeseries for production workloads
  </Card>

  <Card title="Benchmarks" icon="gauge-high" href="/timeseries/benchmarks">
    Ingestion throughput, query latency, and cost for a single node
  </Card>

  <Card title="When to choose Timeseries" icon="scale-balanced" href="/timeseries/comparisons">
    How Timeseries compares to Prometheus, Thanos, Mimir, and managed observability
  </Card>

  <Card title="GitHub" icon="github" href="https://github.com/opendata-oss/opendata/tree/main/timeseries">
    View the source code, open issues, and contribute
  </Card>
</CardGroup>