Metrics, logs, traces, events. One database.
Arc is the columnar analytical database for DevOps and SRE teams who own the observability bill. Unified MELT in one SQL surface. Open Parquet on storage you control. No per-host tax, no cardinality cliff, no choosing what to drop to control cost.
Single Go binary. Open Parquet. Standard SQL.
The shape of the problem
The observability bill keeps climbing. Faster than the team. Faster than the infrastructure. The renewal quote came back up 40 percent for the same data, and someone above is now asking why.
So the workarounds start. Retention gets cut from 30 days to 7. Custom metrics get pruned because each one carries a surcharge. High-cardinality labels like user ID or trace ID get dropped because the index explodes. Logs get sampled.
The data you actually need at 3am during an incident is the data that was already deleted to keep the bill in line.
Then there are the tools. Metrics in one place, logs in another, traces in a third. PromQL here, LogQL there, TraceQL somewhere else. Correlating a metric spike to a log error to the trace that explains it takes three tools and four queries. During an incident.
Arc is the data layer underneath. Unify MELT in one columnar store. Keep full cardinality. Keep months of retention. Query everything in one SQL surface. On storage you already own.
Built for the workloads a real platform runs
Unified MELT
Metrics, events, logs, and traces are all timestamped telemetry. Storing them in separate systems with separate query languages is a historical accident, not a technical requirement. Arc stores all four together as columnar Parquet, queryable in one SQL surface. Joining a CPU spike to the matching log entry to the trace that explains it is a single query.
High cardinality without the penalty
Tag-indexed systems crater when you add user ID, container ID, trace ID, or request ID, because each combination becomes a new indexed series. Arc treats high-cardinality fields as ordinary column data. The labels you actually need for debugging are routine.
Long retention at object-storage prices
Arc stores everything as ZSTD-compressed Parquet on object storage you own, 5-7x smaller than raw. Months of full-resolution logs and metrics cost what object storage costs, not what a per-host vendor charges. The data you need to debug last quarter's pattern is still there.
Keep your existing collectors
Arc ingests line protocol, OpenTelemetry, and Prometheus-style remote write. Existing Telegraf, Fluent Bit, and OTel Collector pipelines point at Arc with a config change. No re-instrumentation, no rip-and-replace.
Real-time dashboards on fresh data
Data is queryable about 100 milliseconds after it lands. Grafana, Superset, and any BI tool that speaks SQL queries the data the moment it arrives. Live dashboards, real-time alerting, and post-incident review all run against the same store.
What Arc gives a platform team
One database, one query language
Standard SQL through DuckDB. PromQL plus LogQL plus TraceQL plus a vendor-specific dashboard query language collapse into one surface every engineer on the team already knows.
Own your data and your bill
Open Parquet on your S3, MinIO, GCS, or Ceph. No egress fee because the data never left your account. No per-host tax because there is no host meter. You pay for object storage plus the compute you choose to run.
No cardinality cliff
Keep the labels that help you debug. Tag with trace ID, user ID, container ID, deploy ID. Arc handles it as column data, not as a runaway index.
Replace the storage layer, not your collectors
Arc replaces Cortex, Mimir, Loki, Tempo, and the storage layer underneath. Keep your existing Prometheus scrapers, Telegraf agents, Fluent Bit forwarders, and OTel Collectors. The operational surface shrinks. The on-call burden shrinks with it.
One binary, no cluster gymnastics
Single Go binary. No Zookeeper, no shard topology, no service mesh. Start with one. Scale by adding nodes when you need to. The platform team operates Arc, not babysits it.
Why DevOps teams choose Arc over the alternatives
Observability SaaS (Datadog, Splunk, New Relic) is operationally polished and financially brutal. The per-host and per-custom-metric pricing model is designed to grow faster than your infrastructure. Arc keeps the Grafana UX on top, replaces the storage layer underneath, and turns the bill into something you control.
OSS stacks (Prometheus + Loki + Tempo + Cortex/Mimir) are free, mature, and three or four tools with three or four query languages. Arc collapses the storage and query layer into one binary and one SQL surface, while keeping your existing collectors. Prometheus scrape configs work as-is via remote write.
Cloud data warehouses (Snowflake, BigQuery) are excellent for BI on quarterly data, expensive for streaming telemetry. The cost of repeatedly querying recent observability data on a warehouse is the kind of thing nobody mentions on the marketing page.
ClickHouse is genuinely fast and operationally heavy. Arc is one binary instead of a cluster, and your data is open Parquet you own, not internal MergeTree format you would have to migrate out of.
Build-it-yourself DuckDB + Parquet is exactly what Arc is. DuckDB plus the streaming ingest path, autonomous compaction, retention policies, auth, governance, and operational tooling. In one binary.
What this looks like in production
Arc is running in production observability workloads today, replacing a mix of legacy time-series databases and over-priced SaaS retention. Unified MELT, full cardinality, multi-month retention on customer-owned object storage. SQL across the whole archive.
AGPL-3.0 with a commercial license for organizations that need it.
Get started
See it run on real telemetry
Our live demos include observability and telemetry workloads against real Arc instances.
Get Arc
Arc is open source and ships as a precompiled single binary. Pull it from the download page as Docker, Helm, or a .deb, and point your existing Telegraf, Fluent Bit, or OTel Collector at it. Source on GitHub.
Talk to us about your bill
For platform teams looking to migrate off observability SaaS or unify a fragmented OSS stack, we run a discovery to scope the migration and the bill it will replace.