Best Database for Observability in 2026

There is no such thing as an observability database, at least not in the way the search term implies. Metrics, logs, and traces are three different storage problems. Metrics are a cardinality problem. Logs are a search problem. Traces are a lookup-by-ID problem with an attribute search bolted on. Every product on this list is good at one or two of those and makes a trade on the third, and the honest way to compare them is to say which trade each one makes. The best database for observability is the one whose trade matches your dominant signal.

I worked at InfluxData. I now run Basekick Labs, where we build Arc, an open, SQL-native time-series database for telemetry you need to keep. Arc is the last entry on this list. It is not a drop-in replacement for a log search engine or a PromQL backend, and I will say exactly where it fits and where it does not. A comparison that never recommends a competitor is an ad.

This is the latest post in a series. The time-series comparison evaluates engines generally, the IoT comparison evaluates them at the edge, the aerospace comparison evaluates them for satellite and flight-test telemetry, and the Prometheus alternatives post goes deep on the metrics tier alone. This one covers all three signals.

Observability is three storage problems

Metrics are numeric samples on a series identified by a set of labels. The hard part is cardinality: every unique label combination is a new series, and engines that keep a series index in memory pay for each one. A user_id or pod_id label is the classic way to take one down.

Logs are semi-structured text with a timestamp and some attributes. The hard part is search: "find every line containing this request ID across 40 services in the last six hours." You can index every token (Elasticsearch, OpenObserve), index only a few labels and scan the rest (Loki), or skip the index and scan columnar data fast (the default in most columnar engines). Each choice moves cost between ingest, storage, and query.

Traces are trees of spans. The common query is "give me trace X," which is a key lookup, followed by "show me slow traces where http.route is /checkout," which is an attribute search over spans. With sampling off, span volume can rival or exceed log volume.

Collection is now mostly a solved, separate problem. OpenTelemetry graduated from the CNCF on May 21, 2026, and the CNCF reports it as the second-highest velocity project after Kubernetes. The specification status page lists tracing, logs, and the metrics protocol as stable, but SDK maturity varies by language: the logs SDK is stable in C++, .NET, Java, PHP, and Rust, a release candidate in Go, and still in development in Python and JavaScript. Profiles reached public alpha in March 2026 and is not meant for critical production use yet. The practical consequence: the database you choose matters less for collection than it did three years ago, and more for what happens after the data lands.

What actually matters when choosing

Rank these against your own workload before you look at anyone's benchmark, including ours.

1. Which signals, in one system or several. Some options are one engine for all three signals. Others are a stack of three products that share a UI. Both work. The second means three things to upgrade, scale, and debug.

2. Log search model. Inverted index on everything, labels only, or columnar scan. If your on-call engineers live in needle-in-a-haystack search, this criterion outranks every other one on this list.

3. Cardinality behavior. Ask what happens when someone adds a high-cardinality attribute on a Friday. "It gets more expensive" and "it falls over" are different answers.

4. Storage format and where it lives. Object storage as the primary tier changes the cost of retention dramatically. An open format (Parquet) changes whether you can read your own history with a different tool. Several options on this list now do one or both.

5. Ingest protocols. Native OTLP, Prometheus remote write, Loki push, Elasticsearch bulk. The more of these a store accepts natively, the cheaper a migration is.

6. Query language. PromQL, LogQL, TraceQL, ES|QL, LogsQL, or SQL. Your dashboards and alert rules are written in one of these, and switching languages is the expensive part of every migration.

7. License and operational weight. AGPL, Apache 2.0, source-available, and proprietary licenses each get vetoed by some legal departments. Kafka as a required dependency is a real operational cost; several options below now require or prefer it.

The observability databases, compared

1. Grafana LGTM (Loki, Tempo, Mimir)

Grafana's stack is three storage products, one per signal, plus Grafana on top and Alloy (Apache 2.0) as the collector. All three backends are AGPL-3.0 and all three use object storage as the primary tier. Current versions are Loki 3.7.8, Tempo 3.1.0, and Mimir 3.2.2.

What it's best at. Cheap log retention and a coherent stack. Loki "only indexes metadata about your logs as a set of labels for each log stream" and stores compressed chunks in object storage, which keeps ingest and storage cheap. It accepts OTLP logs natively, and structured metadata (on by default since 3.0) holds high-cardinality attributes outside the index. Tempo 3.x stores traces as Apache Parquet blocks in object storage ("the only supported block format in Tempo 3.x"), defaults to the vParquet5 schema since 3.1, takes OTLP, Jaeger, and Zipkin, and made TraceQL metrics GA in 3.0. Mimir accepts OTLP and remote write and stores Prometheus TSDB blocks in object storage. If your team already runs Grafana, the vocabulary is familiar and every signal links to the others in the UI.

Where it falls short. Loki is honest about its limits. Its own docs say "Loki was not designed or built to support high cardinality label values," set a default limit of 15 index labels, and tell you not to put trace IDs or order IDs in labels. A search for a string that is not a label is a scan over chunks, and the bloom-filter acceleration meant to speed that up is still experimental in open-source Loki, with no SLA. In April 2026 Grafana announced a new Loki architecture with Kafka-backed ingestion and a redesigned query engine; the press release does not give an open-source availability date, so plan on what ships in 3.x today. Kafka is now preferred for Mimir's ingest storage and required for Tempo in microservices mode. Three backends, three query languages (LogQL, TraceQL, PromQL), three upgrade cycles.

When we ran our own log benchmark, Loki returned success for writes it did not store, because of its per-stream rate limits and out-of-order handling. That is configurable and documented behavior, not a bug, but it is the kind of thing to test before production.

Best for. Teams already on Grafana who want cheap log retention, PromQL for metrics, and a supported path to traces, and who search logs mostly by label.

2. Elasticsearch (and OpenSearch)

Elasticsearch is the incumbent for log search. The current release is 9.5.5 (October 6, 2026). The source is triple-licensed under AGPL-3.0, SSPL, and Elastic License 2.0.

What it's best at. Full-text search. Every token is in an inverted index, so arbitrary search over recent logs is fast and the query surface is the deepest on this list. LogsDB has been GA and the default for new logs data streams since 9.0, and Elastic says it reduces log storage "by up to 60%, with a small impact (10-20%) to indexing performance." 9.5 added native PromQL and a Prometheus remote write endpoint, so Elasticsearch now covers metrics in the PromQL dialect too. The Elastic Distributions of OpenTelemetry went GA in April 2025.

Where it falls short. Cost at retention. Indexing everything is what makes search fast and what makes storage and memory expensive at long retention. Elastic itself added an opt-in Columnar Mode in 9.5, in technical preview, with "no inverted index by default," which we read as a concession worth taking seriously. The native OTLP endpoint is GA for metrics (since 9.2) but only in preview for logs and traces (since 9.5), and the docs warn that it acknowledges a request as a whole, so retried batches can produce duplicate logs or spans. Mappings default to a 1,000-field limit, which matters with free-form attributes. We also wrote up how its PromQL engine works, and compare the two side by side in Arc vs Elasticsearch.

OpenSearch. OpenSearch 3.9.0 (September 29, 2026) is Apache 2.0 and governed by the OpenSearch Software Foundation under the Linux Foundation. It has no OTLP endpoint in core; OTLP arrives through Data Prepper. Its reference observability stack stores logs and traces in OpenSearch but sends metrics to Prometheus, so treat it as a logs-and-traces store.

Best for. Teams whose dominant workload is interactive full-text log search over days to weeks of data, especially if Elasticsearch is already in the building.

3. ClickHouse and ClickStack

ClickHouse is a general-purpose columnar OLAP database, and since it acquired HyperDX in March 2025 it has a packaged observability product, ClickStack: ClickHouse (Apache 2.0), an OpenTelemetry Collector, and the HyperDX UI (MIT). The current release line is 26.9.

What it's best at. Scale and arbitrary slicing. ClickHouse publishes the largest self-reported observability deployment on this list: its internal LogHouse platform at more than 100 PB uncompressed (vendor numbers). The full-text text index became GA in 26.2, so log search no longer has to be a scan, and 26.9 lets supported LIKE and ILIKE patterns use it. The JSON type has been production-ready since 25.3. Managed ClickStack in ClickHouse Cloud went GA in May 2026. It is the most battle-tested open-source engine here for wide-event analytics at very large scale.

Where it falls short. Operational weight and trade-offs you have to tune. ClickHouse's own GA announcement for the text index says insert throughput drops by about half with it enabled, so indexing is a per-table decision, not a default. Self-hosted ClickStack also bundles MongoDB alongside ClickHouse, one more stateful service to run. PromQL support is a Cloud private preview with remote write v1 only, so Prometheus-shaped teams are not the target yet. Schema design (sort keys, codecs, TTLs) decides most of your performance, and getting it right is a skill. We compare the two directly in Arc vs ClickHouse.

Best for. Large platforms with an engineering team that wants SQL over wide events at petabyte scale, and the managed option if you would rather not run it.

4. VictoriaMetrics, VictoriaLogs, and VictoriaTraces

VictoriaMetrics builds one product per signal, all Apache 2.0 with a commercial Enterprise edition. Current versions are VictoriaMetrics v1.154.0, VictoriaLogs v1.53.0, and VictoriaTraces v0.12.0.

What it's best at. Resource efficiency and simple operations. VictoriaMetrics is covered in depth in the Prometheus post; its case studies include adidas, CERN, Roblox, and Spotify. VictoriaLogs stores each log field in its own columnar block, indexes all fields automatically, handles high-cardinality fields out of the box, and supports full-text search through LogsQL. It accepts OpenTelemetry logs natively and also takes Loki push, Elasticsearch bulk, and logs from the Datadog Agent. In our log benchmark, VictoriaLogs was the fastest system on most query types, and I said so at the time.

Where it falls short. VictoriaLogs stores data on local disk only; object storage is for backups, so long retention is a disk-sizing exercise. The FAQ says it works best with log records up to 10 KB, has a hardcoded 2 MB maximum, and tells you not to ingest logs with unbounded JSON keys. VictoriaTraces is explicitly a work in progress whose on-disk format may change, with a 7-day default retention. Downsampling and multiple retention periods for metrics are Enterprise-only.

Best for. Teams that want the lightest-weight self-hosted metrics and logs with fast search, and can live with local-disk storage and a young traces product.

5. GreptimeDB

GreptimeDB is one engine for metrics, logs, and traces, Apache 2.0 at the core, with a few features (read replicas, workload isolation) under a separate enterprise license. 1.0 went GA in April 2026; the current stable is v1.2.1.

What it's best at. Protocol breadth and open storage. It stores data as Parquet with object storage as the primary tier, builds inverted, skipping, and full-text indexes, and accepts one of the broadest sets of ingest protocols on this list: OTLP for all three signals, Prometheus remote write (including 2.0 since 1.2), Loki push, Elasticsearch bulk, Splunk HEC, and InfluxDB line protocol. It speaks both SQL and PromQL over the same data, over MySQL and PostgreSQL wire protocols. If you want to consolidate three backends without rewriting every dashboard, it is the most direct path.

Where it falls short. It is younger than the options above, with a smaller operator community. Native histogram ingestion was experimental and off by default in 1.2.0. Traces are queried through a Jaeger-compatible API rather than a trace query language of its own. Its benchmark against Loki is a vendor benchmark; reproduce it on your data.

Best for. Teams consolidating metrics, logs, and traces into one open-storage engine while keeping PromQL working.

6. OpenObserve

OpenObserve is an observability platform with its own storage engine, AGPL-3.0, with an Enterprise edition under a commercial license. v1.0.0 shipped September 11, 2026, and v1.1.0 added deeper PromQL compatibility and trace critical-path analysis.

What it's best at. A complete product with open storage. It writes Parquet files to object storage, builds a Tantivy inverted index for full-text log search by default, ingests OTLP natively, and queries logs and traces in SQL and metrics in SQL or PromQL, with PromQL coverage deepened in v1.1.0. It ships the UI, alerting, dashboards, RUM, and session replay in one deployment.

Where it falls short. It is the newest 1.0 on this list. The headline "140x lower storage cost" than Elasticsearch on its README is a vendor claim with no independent benchmark behind it. SSO, advanced RBAC, and audit trail are Enterprise features; the self-hosted Enterprise edition is free up to 50 GB of ingest per day.

Best for. Teams that want a single self-hosted product with full-text search over Parquet on object storage, and are comfortable with AGPL.

7. SigNoz

SigNoz is not a database. It is an OpenTelemetry-native observability platform built on ClickHouse, and I include it because many teams evaluating ClickHouse for observability actually want this. The license is MIT except for the ee/ and cmd/enterprise/ directories; the current release is v0.146.0.

What it's best at. The product layer. Its architecture puts ClickHouse underneath and its own OTel Collector in front, which accepts OTLP, Jaeger, Zipkin, and Kafka. Queries run through a query builder or ClickHouse SQL, with PromQL for metrics. You get APM, logs, traces, dashboards, and alerts without assembling them, either self-hosted for free or on SigNoz Cloud at $0.30/GB for logs and traces.

Where it falls short. You inherit ClickHouse's operational model for self-hosting, and the database is an implementation detail you do not choose. Releases are roughly weekly, which is good for features and means you will be upgrading often.

Best for. Teams that want an open-source Datadog-shaped product and are happy to have ClickHouse underneath it.

8. Arc

Arc is an open, SQL-native time-series database for telemetry you need to keep. Storage is Apache Parquet on S3, Azure Blob, MinIO, or local disk; the SQL is PostgreSQL-compatible; it ships as a single Go binary. It has been public since October 2025.

How telemetry gets in: Telegraf. Telegraf has shipped an Arc output plugin upstream since v1.37.0 (December 2025). It groups each batch by measurement into columns and sends them to Arc as gzip-compressed MessagePack, so data arrives already in the columnar shape Arc stores, and the plugin's README cites 3 to 5 times the throughput of line protocol (our own number, since we wrote the plugin). Because Telegraf has more than 300 plugins, one agent covers all three signals:

• OpenTelemetry. The inputs.opentelemetry plugin receives OTLP traces, metrics, and logs over gRPC on port 4317. Point your SDKs, or an OpenTelemetry Collector's OTLP exporter, at Telegraf; spans land in a spans table and logs in a logs table.
• Prometheus. inputs.prometheus scrapes the same /metrics endpoints your Prometheus does, exporters included.
• Logs. syslog, tail, docker_log, and Kubernetes inputs, which is how our OpenShift setup ships cluster logs.
• Everything else. Kafka, StatsD, cloud APIs, databases, and hardware.

A minimal pipeline that takes OTLP from your applications and scrapes Prometheus endpoints looks like this:

[[inputs.opentelemetry]]
  service_address = "0.0.0.0:4317"
 
[[inputs.prometheus]]
  urls = ["http://api:9100/metrics"]
 
[[outputs.arc]]
  url = "http://arc:8000/api/v1/write/msgpack"
  api_key = "$ARC_TOKEN"
  database = "observability"

The Arc plugin writes timestamps at millisecond precision, which is worth knowing if you analyze sub-millisecond span timing.

What it's best at. Telemetry you keep and join. Arc stores metrics, logs, traces, and events as tables in one database, so a question like "error rate by customer tier in the hour after each deploy, for the last 18 months" is one SQL query with a join against your deploy log and customer table, not three tools and a spreadsheet. We walked through that in how Arc shows you the full picture. Cardinality is a column value, not an in-memory series, so a customer_id or pod_id dimension costs storage and scan time but does not take the database down. Retention is a storage bill on object storage you own, and the files are plain Parquet, laid out to be read in place by Spark, Polars, ClickHouse, or any Parquet reader. Ingest is fast: Arc took 4.58 million logs per second with the WAL on in our own log benchmark (first-party, on an M3 laptop).

The shape that fits Arc best is not "replace your log search tool." It is the long-history tier beside it: keep a week or two of logs in a search-indexed store for on-call, and fan the same Telegraf streams out to Arc for a year or more of SQL-queryable history at object-storage prices.

Where it falls short. Arc does not speak PromQL or accept Prometheus remote write, so dashboards and alerts are written in SQL. It builds no full-text index: log search is SQL with LIKE or regular expressions over columnar data, which averaged under 10 ms on 50 million logs in our benchmark but grows with the bytes scanned, so at hundreds of terabytes of hot logs an indexed engine will very likely be faster. Traces are visualized in Grafana through the Arc data source rather than a trace UI of our own. It is the youngest project on this list, public since October 2025. Clustering, RBAC, and tiered storage are in Arc Enterprise; the open-source build is AGPL-3.0.

Best for. Teams already running Telegraf, or happy to, whose observability questions are analytical (trends, SLOs over long windows, joins against business data), who want long retention in a format they own, and who are comfortable with SQL instead of PromQL and LogQL.

If you would rather buy

Managed services remove the storage decision entirely. The trade is price at volume and where your data lives.

List prices, before discounts. To make that concrete with Datadog: 500 GB of logs a day at an average of 1 KB per event is about 15 billion events a month. Ingesting all of it costs about $1,500 a month; indexing all of it at 15-day retention adds about $25,500. Most teams index a fraction, which is why log pipelines and exclusion filters exist.

Cost is the decision driver for most buyers. In Grafana Labs' 2026 Observability Survey of 1,363 practitioners (a vendor survey), cost was the top criterion for selecting tools at 65%, for the third year running, although complexity and overhead (38%) and signal-to-noise (34%) both ranked above cost (31%) as day-to-day concerns.

The market is also consolidating. Palo Alto Networks completed its acquisition of Chronosphere in January 2026, after announcing the deal in November 2025 at $3.35 billion. Snowflake announced it would acquire Observe the same month and closed the deal in February. Datadog acquired Quickwit in January 2025. If a vendor's roadmap is part of your risk model, those events belong in it.

Decision matrix

The query patterns you will actually write

Four patterns cover most observability work. Check your shortlist against all four.

Needle in a haystack. "Every log line containing req_8f2a in the last six hours." Indexed engines (Elasticsearch and OpenObserve with inverted indexes, VictoriaLogs with per-field bloom filters, GreptimeDB, ClickHouse with a text index) are built for this. Loki finds it fastest if the value is a label or structured metadata. Arc scans.

Rate and error budget. "5xx rate per service over five-minute windows." PromQL is very good at this, and rate() handles counter resets for you. In SQL it is a window function, and you handle resets yourself.

Trace lookup and span search. "Trace X," then "slowest spans on /checkout today." Tempo with TraceQL, Elastic APM, and ClickStack or SigNoz on ClickHouse do this with a purpose-built UI. Engines without a trace UI can answer the query but leave the waterfall to Grafana.

Join against the business. "p99 latency by customer plan in the 30 minutes after each deploy, last two quarters." This needs real joins and long retention. SQL engines (ClickHouse, GreptimeDB, OpenObserve, Arc) express it directly, and Elasticsearch's ES|QL has had LOOKUP JOIN since 9.1, against an index in lookup mode. PromQL and LogQL cannot join against a customer table.

If the first pattern is most of your day, choose for search. If the fourth is on your roadmap, do not choose a store that cannot join.

What I left out, and why

Quickwit. A log and trace search engine on object storage, relicensed to Apache 2.0 after Datadog acquired it. It is still maintained (v0.9.2 shipped October 16, 2026, as a security patch), but v0.9.0 in July 2026 was its first numbered release since mid-2024, and the README still lists metrics as "soon." Worth watching, not where I would start a new deployment today.

Prometheus and the PromQL backends (Thanos, managed Prometheus). Metrics-only; covered in full in the Prometheus alternatives post.

InfluxDB and TimescaleDB. Time-series databases that some teams use for metrics, covered in the time-series comparison. Neither is a log or trace store.

Apache Doris and StarRocks. Both appear in observability marketing, and Doris 4.1 added optimizations for log and trace workloads, but I found no 2026 release from either project aimed primarily at general-purpose logs, metrics, and traces.

What changed in 2025 and 2026

• OpenTelemetry graduated (May 2026). Profiles reached public alpha in March 2026.
• ClickHouse acquired HyperDX (March 2025), made its text index GA in 26.2 (early 2026), and made Managed ClickStack GA (May 2026).
• Elasticsearch 9.x made LogsDB the default for new logs data streams (9.0), added native PromQL and remote write (9.5, August 2026), and previewed a Columnar Mode without an inverted index.
• Grafana shipped Tempo 3.0 with Parquet as the only block format (May 2026) and announced a new Kafka-based Loki architecture (April 2026).
• GreptimeDB 1.0 (April 2026) and OpenObserve 1.0 (September 2026) both reached GA, both on Parquet in object storage.
• Consolidation: Palo Alto Networks closed Chronosphere (January 2026), Snowflake bought Observe (closed February 2026), Datadog bought Quickwit (January 2025).
• Telegraf 1.37 (December 2025) shipped an upstream Arc output plugin that writes columnar MessagePack.
• Arc 26.09.1 (September 2026) raised ingest to 34M records/sec in our benchmark and added Iceberg export over the same Parquet files (local-disk deployments only in this first release).

How to choose the best database for observability

Answer seven questions and most of the field disappears:

1. Already on Grafana, logs searched mostly by label, want PromQL? → Grafana LGTM.
2. Interactive full-text log search is the core workload? → Elasticsearch, or OpenSearch if you need Apache 2.0.
3. Very large scale, a platform team, and SQL over wide events? → ClickHouse with ClickStack.
4. Lightest self-hosted footprint for metrics and logs, local disk is fine? → VictoriaMetrics and VictoriaLogs.
5. One engine for all signals, open storage, keep PromQL? → GreptimeDB, or OpenObserve if you want the whole product in one deployment.
6. Want an open-source APM product, not a database? → SigNoz.
7. Observability questions are analytical, retention is long, and the data must stay in a format you own? → Arc, usually beside a short-retention search tier rather than instead of it.

And do not pick from a blog post, including this one. OpenTelemetry makes testing unusually cheap: add a second exporter to your Collector, send a real week of telemetry to your top two candidates, and measure ingest during your peak hour, p99 on your five most-used queries, storage after a week, and how many dashboards and alerts needed rewriting. Every vendor multiplier in this post, mine included, is marketing until you reproduce it.

FAQ

What is the best database for observability? It depends on which signal dominates your work. For full-text log search, Elasticsearch, OpenObserve, and VictoriaLogs. For Grafana-native teams who search logs by label, the LGTM stack. For petabyte-scale wide events, ClickHouse. For one open-storage engine across all signals with PromQL, GreptimeDB. For long-retention analytical questions in SQL over data you own, Arc. Shortlist two and test them with your own telemetry.

Can one database store metrics, logs, and traces? Yes. Elasticsearch, ClickHouse, GreptimeDB, OpenObserve, and Arc all store all three signals in one engine. Grafana and VictoriaMetrics use a separate product per signal. One engine means fewer moving parts and cross-signal joins; separate products let each one specialize.

Which observability databases store data in Parquet? Grafana Tempo stores traces in Parquet blocks. GreptimeDB and OpenObserve store all signals as Parquet, with object storage as the primary tier. Arc stores everything as plain Parquet on object storage or local disk. ClickHouse reads and writes Parquet but stores data in its own MergeTree format.

Why is Loki cheaper than Elasticsearch for logs? Loki indexes only a small set of labels per stream and keeps compressed log chunks in object storage, so ingest and storage are cheap. Elasticsearch indexes every token, which makes arbitrary search fast but costs more storage and memory. The trade is query speed for text that is not a label.

Does Arc support OpenTelemetry? Yes, through Telegraf. Telegraf's OpenTelemetry input receives OTLP traces, metrics, and logs over gRPC, and its Arc output plugin, upstream since Telegraf 1.37, writes them to Arc as columnar MessagePack. Point your SDKs or your Collector's OTLP exporter at Telegraf, and the same agent can scrape Prometheus endpoints and collect syslog alongside.

How much does Datadog cost for logs? At list price, $0.10 per GB ingested, plus $1.70 per million events indexed with 15-day retention on an annual plan. Indexing is usually the larger part of the bill, which is why teams index only a subset and archive the rest.

What is the best open-source observability database? Grafana Loki, Tempo, and Mimir (AGPL-3.0), VictoriaMetrics and VictoriaLogs (Apache 2.0), ClickHouse (Apache 2.0), GreptimeDB (Apache 2.0), OpenObserve (AGPL-3.0), OpenSearch (Apache 2.0), and Arc (AGPL-3.0) are all open source. Elasticsearch's source is offered under AGPL-3.0 as one of three licenses, though features in its default distribution are under the Elastic License. Choose by search model and retention needs first, license second.

This post will be updated quarterly. Last updated October 2026. If something here is wrong or out of date, tell me on GitHub or in Discord.

Related reading:

• 7 Prometheus Alternatives in 2026
• 6 Best Time-Series Databases in 2026
• We Benchmarked Arc Against Every Major Log Database
• Elasticsearch Just Admitted What Columnar Databases Have Known for a Decade
• I Replaced Our Entire OpenShift Observability Stack With One Database
• Why Context Matters: How Arc Shows You the Full Picture
• Parquet vs Proprietary Formats

Explore Arc:

• Arc for DevOps and Observability
• Arc documentation
• Compare Arc vs Elasticsearch
• Compare Arc vs ClickHouse
• Star Arc on GitHub

About the author. I am Ignacio Van Droogenbroeck, founder of Basekick Labs and an ex-InfluxData engineer. I spent years as a DevOps engineer jumping between a metrics tool, a log tool, and a tracing tool during incidents, and I built Arc because I believe telemetry should live in open, columnar formats you can query with SQL and keep for as long as it is useful. The other options on this list are real choices for the right team. If yours is a team whose observability questions have turned into analytics questions, I would like you to try Arc.