Keep every telemetry reading.
Query the whole history.
Arc is a lightweight, SQL-native time-series database for high-volume telemetry.
Ingest through InfluxDB Line Protocol, store open Parquet on the storage you own, and query recent and historical data together, without retention cliffs, proprietary storage, or a separate cold-data stack.
docker run -d -p 8000:8000 \
-e STORAGE_BACKEND=local \
-v arc-data:/app/data \
ghcr.io/basekick-labs/arc:latestOne container. No agents, no required external dependencies.
- Open source
- Telegraf-compatible
- Single binary
- S3, Azure, MinIO, or local storage
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.
Why Arc
Four decisions that follow from keeping the data
compression observed on representative telemetry workloads
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.
no proprietary query language to learn
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->an open format, on storage you control
Own the data in open Parquet
Files land in your S3, Azure Blob, MinIO, or local disk. Read them from Arc, Spark, Polars, or ClickHouse. Leaving Arc does not require an export step, because there is nothing to export from.
Learn more->binary, no external dependencies required
Deploy one lightweight binary
A single Go binary with no required external dependencies. Docker, Kubernetes via Helm, or a native package. No coordinator, no JVM, no separate query tier to operate.
Learn more->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
- 1
Ingest telemetry
InfluxDB Line Protocol or Arc's native MessagePack columnar protocol. Existing Telegraf agents point at Arc with a URL change.
- 2
Store open Parquet
Arc writes Apache Parquet to storage you own and compacts it in the background. No cron job, no Spark cluster.
- 3
Query with SQL
Recent and historical data in the same statement. Results over HTTP as JSON, or over the Arrow IPC endpoint.
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…
Where teams run Arc
The workloads look different. The shape of the problem does not.
Industrial IoT
Keep sensor history across every machine, vendor, and site without building a separate cold-data pipeline.
Manufacturing
Correlate line telemetry against quality events months later, at the sample rate the process actually ran at.
Energy and utilities
Hold meter and grid telemetry at full resolution for the long windows that regulatory and load analysis need.
Fleet and logistics
Track position and vehicle telemetry across a growing fleet without the per-asset cardinality becoming the bottleneck.
Aerospace telemetry
Retain full-rate flight and mission telemetry, and query an entire archive in one SQL statement.
Observability
Keep metrics and event history past the usual retention window, and query it with SQL instead of a bespoke language.
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.