arc is a free, open source data warehousing & processing project written in Go and released under AGPL-3.0. It has 676 GitHub stars, 52 forks and 57 open issues, and was last pushed 29 hours ago. On this registry it ranks #9 of 9 tracked projects in Data Warehousing & Processing, with 5 head-to-head comparisons available.

What is arc?

Arc is an open, SQL-native time-series database, released under AGPL-3.0, for engineers and platform teams who need to keep full-resolution telemetry from machines, services, vehicles, and devices and still query recent and historical data together in one system.

What it is

Arc is a complete time-series analytical database delivered as a single Go binary. It bundles an ingestion pipeline, a Parquet storage engine, a compaction system, a SQL query layer, a retention policy manager, a continuous query scheduler, and telemetry integrations. It uses DuckDB as its query engine, while Arc supplies the parts 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. Data lands as open Apache Parquet on local disk, S3, or Azure. Arc is explicitly not a wrapper; it does not expect users to bring their own ingestion, compaction, or retention policies.

The concrete problem is the cost of keeping telemetry rather than the cost of collecting it. Teams evaluating a time-series database hit the same walls: retention cliffs, where older data is downsampled, exported, or deleted because storage costs grow; split hot and cold paths, where recent data is queryable in one system while history waits in a warehouse or object store; operational overhead, where a simple workload turns into a PostgreSQL extension stack or a multi-service cluster; migration friction, because existing agents, dashboards, and Line Protocol writers make switching risky; and vendor lock-in from proprietary storage. Arc replaces that PostgreSQL extension stack or multi-service cluster with one binary, and keeps full-resolution history queryable alongside recent data.

Key capabilities

  • Ingests 34M+ records per second and answers queries at 8.42M rows per second.
  • Speaks InfluxDB Line Protocol and is Telegraf compatible, so existing writers and agents keep working.
  • Exposes standard analytical SQL through DuckDB, including window functions, CTEs, joins, and aggregations.
  • Writes open Apache Parquet files to local disk, S3, or Azure, so the data stays portable.
  • Runs retention policies and continuous queries as scheduled in-process work, alongside authentication, backup and restore, compaction, and enterprise clustering.
  • Ships air-gap ready as a single binary with no external service dependencies described in the README.
  • Includes two optional front ends: Arc Launchpad, a self-hosted web console with a SQL console, schema explorer, logs, monitoring, and management for tokens, retention, alerts, continuous queries, and MQTT ingestion, deployed beside Arc with Docker Compose; and arcli, a command line with named connections, SQL output as table, JSON, CSV, or Arrow, line-protocol and MessagePack writes, bulk imports, and admin for tokens, retention, continuous queries, backups, and compaction.

Who uses it and how

  • Aerospace telemetry programs, which the README names as the workload Arc was built for.
  • IoT and edge deployments, reflected in the project topics for edge computing, IoT, and events.
  • Observability and logging teams that need to retain full-resolution history for debugging and compliance instead of downsampling it away.
  • Teams already running InfluxDB Line Protocol writers or Telegraf agents that want to change the storage layer without rebuilding collection.
  • Operators in air-gapped or self-hosted environments who run Arc beside Launchpad using Docker Compose for a browser console.

Getting started

Run the single Go binary (Go 1.26 or newer) and write to it over InfluxDB Line Protocol. Optional clients install separately: arcli with brew install basekick-labs/tap/arcli or from deb, rpm, Arch, and Docker packages, and Arc Launchpad with Docker Compose. Documentation lives at docs.basekick.net/arc.

How it compares

The facts provided do not include a list of paid products that Arc replaces, so no licence-and-cost comparison against named commercial vendors can be made here. Among the tools the README does name, Arc sits where InfluxDB-compatible ingestion meets a DuckDB query engine, and it positions itself as the alternative to a PostgreSQL extension stack or a multi-service time-series cluster rather than as a layer on top of one.

When to use it — and when not to

A self-hoster must operate the binary plus whatever storage it writes to — local disk, S3, or Azure — and should expect to manage retention policies, continuous queries, tokens, and backups, optionally through Launchpad or arcli. Teams that cannot accept AGPL-3.0 copyleft terms, or that want a managed service with a long third-party integration catalog, should look elsewhere. The project's community signals are modest, at 676 stars, 52 forks, and 57 open issues, though it is actively developed, with the last push in September 2026.

project readme (upstream, from github) — read inline

Arc

Ingestion Query Go License

Docs Website Discord GitHub

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:

  1. Point a small slice of ingestion at Arc, or dual-write to both systems.
  2. Compare the data and query results over an overlapping time window.
  3. Move one dashboard or workload at a time.
  4. 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

readme truncated — read the full docs on github

Frequently asked questions

Is arc free to use?

arc is open source under the AGPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does arc do?

Open, SQL-native time-series database for telemetry you need to keep. 34M+ records/sec ingestion, 8M+ rows/sec queries. InfluxDB Line Protocol and Telegraf comp

What is arc written in?

arc is primarily written in Go. Its source is publicly available at https://github.com/Basekick-Labs/arc, and it has 676 GitHub stars.