Drill: No decoration: a landing page using ONLY typography, spacing, and alignment. No gradients, no illustrations, no decorative SVG, no glassmorphism. Target: looks designed, not empty.
Interpretation: Built as Stratum — a full-resolution metrics observability platform (no sampling, columnar storage). Domain picked for maximum content density: technical specifics (SQL queries, cardinality, comparison table, ASCII architecture diagram) give typography substance to organize without decoration. Aesthetic reference: Mintlify/Stripe-docs editorial restraint on a marketing surface — warm-white canvas, Inter + JetBrains Mono, pure monochrome.
Most metrics platforms downsample after 24 hours. Stratum doesn't. A column-oriented storage engine keeps every value at 1-second granularity for the full retention window — so the anomaly at 3 AM Tuesday is still queryable on Friday, at the resolution it happened.
Full-resolution storage, always. When you query p99 latency for a specific route over the last 30 days, you get the actual p99 computed from every datapoint — not an estimate interpolated from 5-minute rollups. The storage engine is a custom columnar format optimized for time-series range scans. Data is ingested via OpenTelemetry OTLP, Prometheus remote-write, or the native HTTP API. Every write is durably replicated before acknowledgment.
Cardinality that doesn't punish you.
High-cardinality labels (user_id, container_name,
request_id) are the reason most teams hit cardinality limits and lose data.
Stratum's storage engine treats labels as dictionary-encoded columns, not as pre-computed
series identifiers. A label with 2 million distinct values costs the same storage as one
with 20 — the dictionary lookup is O(1) at query time. This is why the 42ms query above
runs against 10M active series without a pre-aggregation step.
Query in SQL or PromQL.
The query engine supports both PromQL (for teams migrating from Prometheus or Grafana) and
standard SQL with time-series extensions (for teams who want JOINs across
metrics and dimensions). Both hit the same storage layer; neither triggers a fallback to
downsampled data. Dashboards built in Grafana connect via the standard Prometheus
datasource — no plugin required.
No sampling on ingestion. The OTLP collector and remote-write receiver accept every datapoint the upstream sends. There is no tail-based sampling, no head-based sampling, no adaptive sampling. If your application emits 50,000 datapoints per second, Stratum stores 50,000 datapoints per second. The only data loss is what you explicitly configure via drop rules.
| Capability | Stratum | Prometheus + Thanos | Datadog |
|---|---|---|---|
| Native granularity | 1s | 15s | 10s → 5m rollup |
| After 24h | 1s, unchanged | 15s | 1m rollup |
| After 7d | 1s, unchanged | 15s (or downsampled) | 1h rollup |
| After 30d | 1s, unchanged | typically 1m+ rollup | 1h rollup |
| Cardinality ceiling | none (columnar) | ~10M active series | tier-based, 100K custom |
| p99 over 30d at 1s granularity | 42ms · exact | n/a (15s granularity) | estimate from rollups |
| Query language | SQL + PromQL | PromQL | proprietary + PromQL |
| Data ownership | self-host or cloud | self-host | cloud only |
Most metrics platforms store data as (series_id, timestamp, value) triples in a
key-value store (often Cassandra, ScyllaDB, or a custom LSM). This works well when the
cardinality of series_id is low and stable. It breaks down when labels carry
high-cardinality values — each unique label combination creates a new series, and the
KV-store's write amplification grows linearly with series count. The standard response is
to limit cardinality and downsample old data. Stratum takes a different approach.
/v1/write) ──→ · dictionary-encoded labels SQL client ──→ Dashboards
│ · Gorilla-compressed values PromQL engine ──→ Alerting
│ · partitioned by time + tenant SQL engine ──→ Notebooks
▼ · replicated (Raft, 3x)
Durably acked
(no sampling)
The storage layer writes data into time-partitioned segments. Each segment is a columnar
file: label columns are dictionary-encoded (a label value appears once in a dictionary,
referenced by integer ID in the column), timestamp columns use delta-of-delta encoding, and
value columns use Gorilla compression. This means a label like user_id with
500,000 distinct values adds ~4 bytes of dictionary overhead per value, not 500,000 new
series entries. A query filtering by user_id = '12345' is a dictionary lookup
followed by a bitmap scan — not a scan of 500,000 separate series.
We spent two years fighting cardinality limits on our previous platform — dropping labels,
pre-aggregating, writing custom rollup jobs. The first week after migrating to Stratum, we
added request_id as a label on every metric. That alone cut our incident
investigation time in half, because we could finally correlate a slow query to a specific
request without jumping between three tools.
$0 for the first 1 million datapoints per month. Then $0.40 per additional million, all at full resolution.
Self-hosted is free and open core (Apache 2.0). Cloud includes replication, retention management, and the query API. No data tiers, no resolution tiers, no "contact sales" for a per-metric price list.
Point your existing OpenTelemetry collector or Prometheus remote-write at a Stratum endpoint. Your dashboards work unchanged. Your queries return real numbers, not estimates.