Open source time-series database
Keep every telemetry reading. Query the whole history.
Arc ingests through InfluxDB Line Protocol, stores open Parquet on storage you own, and queries recent and historical data together with SQL. No retention cliffs, no proprietary formats, no separate cold-data stack.
docker run -d -p 8000:8000 \
-e STORAGE_BACKEND=local \
-v arc-data:/app/data \
ghcr.io/basekick-labs/arc:latest- Open source
- Telegraf-compatible
- Single binary
- S3, Azure, MinIO, or local storage
Simulated stream. A real query against a live Arc instance runs below.
Performance
34M
records/sec
sustained ingestion, MessagePack columnar protocol
9.2M
rows/sec
query throughput over the Arrow IPC endpoint
5-7x
compression
observed on representative Parquet telemetry workloads
First-party numbers, measured on our own hardware. Benchmark against your own workload before trusting anyone's figures — including ours.
The problem
Keeping telemetry is harder than collecting it
Telemetry volume only goes up. More machines, more sensors, higher sample rates. The data grows faster than the budget for storing it, and something has to give.
Usually it is the history. Downsample after thirty days, drop raw readings after ninety. It works right up until the moment you need to investigate a failure from last year and find the resolution you needed is gone.
The workaround splits the data in two: a fast store for recent readings, a warehouse or cold archive for everything older. Now there are two systems, two query languages, and a join you cannot write.
Leaving is expensive too. When the storage engine is the vendor, migration means a rewrite, so a pricing change is difficult to answer. And the alternatives that fix this often want a cluster, a coordinator, and an operator before they will hold a single row.
A typical time-series stack, as data ages
Arc, over the same window
Why Arc
Four decisions that follow from keeping the data
Keep full-resolution history
Parquet compresses telemetry well enough that keeping raw readings stops being the expensive option. No downsampling schedule, no retention cliff to defend in a design review.
Query hot and historical together
One SQL surface over recent and archived data. PostgreSQL-compatible SQL through an embedded DuckDB engine, including window functions, CTEs, and joins.
Learn more->Own the data in open Parquet
Files land in your S3, Azure Blob, MinIO, or local disk. Leaving Arc does not require an export step, because there is nothing to export from.
Learn more->Deploy one lightweight binary
A single Go binary with no required external dependencies. Docker, Kubernetes via Helm, or a native package.
Get the binary->Migration
Coming from InfluxDB
Ingestion is the part that usually blocks a migration. Arc speaks Line Protocol, so that part is a configuration change rather than a rewrite.
We help with migration at no cost. Guides also exist for TimescaleDB, ClickHouse, and QuestDB.
InfluxDB Line Protocol, natively
The payload your writers already emit does not change.
Telegraf keeps working
Point your existing output at Arc and change the URL.
Dual-write during cutover
Run both, compare the same window, switch when you are satisfied.
Bring the history with you
tsm2arc reads 1.x and 2.x TSM files off disk with resumable checkpoints.
Try it locally first
Replay a slice of production into a container before committing anything.
How it works
Three moving parts, one binary
Telemetry goes in, Parquet lands on your storage, SQL comes out. That is the whole system.
01 · TELEMETRY IN
Your existing writers
Existing Telegraf agents point at Arc with a URL change. High-volume writers use the native columnar protocol.
Ingest — Line Protocol and MessagePack endpoints, optional WAL
Compact — background Parquet compaction, no cron job, no Spark
Query — embedded DuckDB engine, PostgreSQL-compatible SQL
03 · SQL OUT
Any SQL client
Recent and historical data in the same statement. Window functions, CTEs, and joins included.
02 · YOUR STORAGE
Open Parquet, on infrastructure you own
Time-partitioned Apache Parquet, readable by DuckDB, Spark, Polars, or ClickHouse directly. Leaving Arc needs no export step — the files are already yours.
See Arc running
A real query, on real data
The panel beside this one is not a recording. It runs a SQL aggregate against a live Arc instance holding the public New York Citibike trip dataset, and shows what came back along with how long the round trip took.
The query is time-ranged on purpose. Bounding a window means Arc only reads the partitions it needs, which is the difference between scanning an archive and scanning a slice of it.
Loading query…Running against live Citibike trip data…
Ecosystem
A UI to run it, and the tools you already use
Arc is a single binary, but it does not arrive alone.
Collect
existing agents keep workingVisualize
dashboards and ad-hoc queriesQuery & analyze
from code, or straight off the ParquetAnything that reads Parquet or speaks HTTP can talk to Arc — the storage format and the API are both open. Integration docs
Where teams run Arc
The workloads look different. The shape of the problem does not.
Proof of capability
Built for aerospace telemetry. Useful anywhere machines never stop producing data.
Flight and mission telemetry is the hardest version of this problem: very high sample rates, no tolerance for gaps, and archives that stay queryable for years. The same properties matter on a factory floor, a substation, or a fleet.
See the aerospace and defense workload->Evaluate Arc against your workload
Head-to-head numbers, methodology, and the migration path for each. Benchmark against your own data before you trust anyone's published figures, including ours.
Arc vs InfluxDB
Line Protocol compatibility, so ingestion moves with a URL change.
Arc vs TimescaleDB
Leaving the Postgres executor behind for columnar analytical scans.
Arc vs ClickHouse
Open Parquet on your storage instead of a native engine format.
Arc vs Elasticsearch
Structured telemetry in columnar storage rather than an inverted index.
Licensing
The community edition is genuinely the product, not a trial. Commercial licensing exists for teams whose legal position rules out AGPL, or who need clustering and a support agreement.
Community
AGPL-3.0
The full database, free to run anywhere. Single-node deployment, token-based authentication, local and object storage backends, manual retention and continuous queries.
Download Arc->Enterprise
Commercial licence
Adds multi-node clustering and failover, role-based access control, LDAP/SAML/OIDC integration, audit logging, hot and cold tiering, managed backup and restore, and a support agreement. Core-based licensing, from $5,000 per year.
Enterprise details->Arc Enterprise Managed
Managed hosting
Arc deployed on dedicated infrastructure and operated by Basekick Labs, with Enterprise features included. Sized to your workload rather than sold in fixed tiers.
See managed hosting->AGPL-3.0 obligations apply to the community edition. If your organisation restricts copyleft licences, the commercial licence removes that obligation. Full terms are on the terms page, and we are happy to send them to your counsel before you evaluate.
Join our community
Get help, share what you've built, and shape where Arc goes next. Engineers from the Arc team are active across all three channels.
Go to The Dive: Arc community forumLatest from the blog
Benchmarks, deep-dives, and release notes from the Arc team.
Start with one container
Run Arc locally, write a point, and query it back. If it fits, we can help you plan the migration and the production deployment.
Prefer to read first? The documentation covers ingestion, storage backends, and query. Or watch Arc replay live mission telemetry and see the other demos running on open data feeds.