Skip to content
Home

Migrations

Write to your bucket. That's the migration.

Cardinal is S3-first. Telemetry lands in your object storage from the OpenTelemetry Collector, Vector, Fluent Bit, or code you wrote yourself. A stateless query engine sits downstream, serving Grafana, the Cardinal UI, and agents in Claude, Codex, Gemini, and Cursor. There's no vendor storage to trust, and no proprietary agent to install.

SourcesOpenTelemetry Collector+ AWS S3 exporterAny S3 writerVector · Fluent Bit · your codeObject Storageyour S3 · GCS · Azure Blob bucketthe boundaryCardinal Query Enginestateless · elastic · sits downstream of S3runs in your VPCClaudeCodexGeminiCursorGrafanaCardinal UIConsumers

S3

the only durable storage in the path

0

proprietary agents on your hosts

any

OTEL-compatible or custom S3 writer

Why S3-first changes what "migration" means.

In a traditional stack the vendor owns storage. Switching means moving the data. When the bucket is yours, the switch is upstream and downstream of a boundary that never moves.

Your bucket is the boundary

Cardinal indexes what's already in your object storage. Nothing to hand over, no vendor storage to trust; the migration is just "start writing to your own S3".

OpenTelemetry is the on-ramp

The OTEL Collector with the AWS S3 exporter writes straight into your bucket. Whatever the Collector can receive converts on the way through, so there's no proprietary agent to install and no Cardinal-specific SDK in your services.

The query engine is downstream, and stateless

Cardinal doesn't own your data; it reads from S3 on demand. Scale readers up during cutover, down when quiet. Nothing to migrate at the query layer either.

Consumers stay pluggable

Same data serves Grafana, the Cardinal UI, and agents in Claude, Codex, Gemini, or Cursor. Swapping the query engine later doesn't touch instrumentation or storage.

How to move.

Four mechanical steps. Run both stacks in parallel for as long as you need. The boundary is your bucket, so nothing forces a hard cutover.

  1. 01

    Point the Collector at your bucket

    Add the AWS S3 exporter to your OTEL Collector and aim it at an S3 prefix. Cardinal indexes what lands there.

  2. 02

    Run in parallel

    Keep your incumbent live. Cardinal indexes the same data path in the background. Compare results side-by-side for as long as you want.

  3. 03

    Move the readers

    Point Grafana, the Cardinal UI, and agents at Cardinal. The bucket doesn't move; the query surface does.

  4. 04

    Retire the incumbent's hot storage

    As retention windows overlap, wind down the vendor's ingest and indexed storage. Your OTEL config stays where it is, portable for whatever's next.

Point a writer at a test bucket and see it work.

The fastest way to evaluate Cardinal is to spin up a bucket, drop some telemetry in, and query it. Everything after that is optional.

Start a migrationRead the docsCompare vendors →