Arc
Open, SQL-native time-series database for telemetry you need to keep. Arc ingests 34M+ records/sec, stores data as standard Parquet on infrastructure you own, and lets you query recent and historical data together. InfluxDB Line Protocol and Telegraf compatible. Single binary. AGPL-3.0.
Prefer a UI? Arc Launchpad is a self-hosted web console for the Arc instances you run — SQL console, schema explorer, logs, monitoring, and management for tokens, retention, alerts, continuous queries, and MQTT ingestion. Deploy it alongside Arc with Docker Compose. Docs.
Prefer a terminal? arcli is the Arc command line — named connections, SQL queries with table, JSON, CSV or Arrow output, line-protocol and MessagePack writes, bulk imports, and admin for tokens, retention, continuous queries, backups and compaction.
brew install basekick-labs/tap/arcli, or deb, rpm, Arch and Docker. Docs.
Telemetry is easy to collect and expensive to keep
Machines, services, vehicles, and devices produce data continuously. The operational problem is not only ingesting the latest readings — it is keeping the full-resolution history available for debugging, analysis, compliance, and the next question nobody has asked yet.
Teams evaluating a time-series database usually run into the same trade-offs:
- Retention cliffs: Older data is downsampled, exported, or deleted because storage costs grow too quickly.
- Split hot and cold paths: Recent data is queryable in one system while historical data waits in a warehouse or object store.
- Operational overhead: A simple workload turns into a PostgreSQL extension stack or a multi-service cluster.
- Migration friction: Existing agents, dashboards, and Line Protocol writers make changing databases risky.
- Vendor lock-in: Proprietary storage makes it difficult to use your data elsewhere or leave later.
Arc is built for teams that want to keep the data, query the whole history, and start with a small deployment. It combines high-throughput ingestion, automatic Parquet storage and compaction, analytical SQL, retention policies, and continuous queries in one binary.
Built for aerospace telemetry. Useful anywhere machines never stop producing data.
What Arc is (and isn't)
Arc is a complete time-series analytical database: ingestion pipeline, Parquet storage engine, compaction system, SQL query layer, retention policy manager, continuous query scheduler, and telemetry integrations — in one binary. It uses DuckDB as its query engine, while Arc adds the pieces needed to run a durable ingestion and analytics service: high-throughput writes with automatic Parquet flushing, background compaction, scheduled compute, data lifecycle management, authentication, backup and restore, and enterprise clustering.
Arc is not a wrapper. You don't bring your own ingestion, compaction, or retention policies. Arc provides the full stack.
Why teams evaluate Arc
- Keep full-resolution history instead of choosing between retention and cost.
- Use standard SQL with window functions, CTEs, joins, and analytical aggregations.
- Own the files: Arc stores data as open Apache Parquet on local disk, S3, Azure, or MinIO.
- Start small: run one binary on a laptop, edge box, or server before adding enterprise clustering.
- Migrate gradually: use InfluxDB Line Protocol and Telegraf-compatible ingestion to dual-write and validate before cutover.
When Arc may not be the right choice
- If your workload is primarily transactional relational data and already fits comfortably in PostgreSQL, start by evaluating TimescaleDB.
- If you need a mature metrics-only replacement for Prometheus and depend on PromQL, evaluate VictoriaMetrics.
- If your organization cannot approve AGPL-3.0 software, use Arc Enterprise's commercial license or choose an Apache-licensed alternative.
- If you need the largest established community and the lowest adoption risk, Arc is newer than TimescaleDB, VictoriaMetrics, and QuestDB.
-- Telemetry: hourly sensor summary across a full history
SELECT
device_id,
DATE_TRUNC('hour', timestamp) AS hour,
AVG(value) AS average_value,
MIN(value) AS minimum_value,
MAX(value) AS maximum_value
FROM telemetry.sensor_readings
WHERE timestamp > NOW() - INTERVAL '30 days'
GROUP BY device_id, hour
ORDER BY hour DESC;
-- Telemetry: correlate readings with device metadata
SELECT
d.site,
r.device_id,
AVG(r.value) AS average_value
FROM telemetry.sensor_readings AS r
JOIN telemetry.devices AS d ON d.device_id = r.device_id
WHERE r.timestamp > NOW() - INTERVAL '24 hours'
GROUP BY d.site, r.device_id;
Standard SQL. Window functions, CTEs, joins, aggregations. No proprietary query language.
Start with the workload you already have
Arc accepts InfluxDB Line Protocol directly, so existing Telegraf inputs can write to Arc without changing the collection layer. A low-risk migration usually looks like this:
- Point a small slice of ingestion at Arc, or dual-write to both systems.
- Compare the data and query results over an overlapping time window.
- Move one dashboard or workload at a time.
- Decommission the old database only after a full retention cycle has passed.
See the InfluxDB migration guide, or compare Arc with TimescaleDB, InfluxDB, ClickHouse, and Elasticsearch.
Live Demo
See Arc in action: https://basekick.net/demos
Performance
Benchmarked on Apple MacBook Pro M3 Max (14 cores, 36GB RAM, 1TB NVMe). Test config: 12 concurrent workers, 1000-record batches, columnar data.
Ingestion (August 2026)
| Protocol | Throughput | p50 Latency | p99 Latency |
|---|---|---|---|
| MessagePack Columnar | 34.0M rec/s | 0.29ms | 1.40ms |
| MessagePack + Zstd | 24.9M rec/s | 0.42ms | 1.53ms |
| MessagePack + GZIP | 24.6M rec/s | 0.42ms | 1.53ms |
| Line Protocol | 4.7M rec/s | 2.19ms | 6.61ms |
All rows measured over a 60-second sustained run. The MessagePack Columnar row is 2,043,451,000 records ingested in 60 seconds — and that's not rows streamed into a memory buffer: every record was received over HTTP, decoded, time-sorted, and durably written to disk as queryable Parquet, at 0.29ms median latency, on a laptop.
These numbers ship in 26.09.1: ingest no longer dictionary-encodes Parquet (compaction re-encodes files anyway) and the msgpack columnar path now decodes payloads directly into typed column arrays, eliminating per-value allocations — see the 26.09.1 release notes.
Compaction
Automatic background compaction merges small Parquet files into optimized larger files:
| Metric | Before | After | Reduction |
|---|---|---|---|
| Files | 43 | 1 | 97.7% |
| Size | 372 MB | 36 MB | 90.4% |
Benefits:
- 10x storage reduction via better compression and encoding
- Faster queries - scan 1 file vs 43 files
- Lower cloud costs - less storage, fewer API calls
Query (May 2026)
Arc speaks three wire formats from the same query engine. Arrow IPC is the throughput leader for analytical clients (Grafana, pyarrow, polars) that can take an Arrow dependency — zero-copy from the engine's internal columnar buffers. MessagePack (columnar, stable as of 26.09.1) is the choice for clients that don't speak Arrow but want smaller bytes and faster decode than JSON — same envelope shape as JSON, native binary types for timestamps and binary columns. JSON stays the default for ergonomic compatibility.
Benchmark: 393.7M-row cpu measurement, 5 iterations per query, M3 Max. Latency is p50 in milliseconds. The five SELECT-LIMIT rows were measured back-to-back in the same session so the three columns are ap