Uptrace: OpenTelemetry APM Backed by ClickHouse and PostgreSQL
Open source APM: OpenTelemetry traces, metrics, and logs
At a glance
- What is it?
- Uptrace is an open source APM that stores OpenTelemetry traces, metrics, and logs in ClickHouse, with PostgreSQL holding metadata. It targets teams that want a self-hosted single UI for all three signals, and the AGPL-3.0 licence is the first thing to check before adopting it.
- Who is it for?
- Adopt Uptrace if you already emit OpenTelemetry data, want traces, metrics, and logs in one self-hosted UI, and are comfortable running ClickHouse and PostgreSQL alongside each other. Do not adopt it if AGPL-3.0 obligations are incompatible with your distribution model, or if you need a stable release rather than a beta line.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap Uptrace Fills: One Backend for Three OpenTelemetry Signals
Most self-hosted observability stacks end up as two or three separate systems. Traces go to one store, metrics to Prometheus, logs to something else, and the engineer troubleshooting an incident switches between three query languages and three UIs. Uptrace's stated position is that it is an open source APM supporting distributed tracing, metrics, and logs behind a single UI. The README lists a service graph, chart annotations, 50+ pre-built dashboards that appear once metrics start arriving, and alerting with notifications over Email, Slack, WebHook, and AlertManager.
The audience is fairly narrow and worth naming. This is for teams already committed to OpenTelemetry as the collection framework, because that is the ingestion path the project is built around. It is also for teams willing to operate ClickHouse, which is not a small ask. The README claims Uptrace can process billions of spans and metrics on a single server, and that a 1KB span compresses to roughly 40 bytes on disk. Those are the project's own figures, not measurements made here. If your data volume is modest, the compression argument matters less than the operational cost of the database.
Two Databases, Two Jobs: ClickHouse for Signals, PostgreSQL for Metadata
The architecture is stated plainly in the README: OpenTelemetry collects the data, ClickHouse stores it, and PostgreSQL stores metadata such as metric names and alerts. That split is the single most important design decision to understand before deploying.
ClickHouse is a columnar store, which is what makes the compression and scan performance claims plausible for append-heavy span data. PostgreSQL carries the relational, mutable state: the catalogue of metric names, alert definitions, and presumably the user and project records referenced by the YAML configuration feature. The consequence is that a Uptrace deployment is never one process. You are running at least two stateful databases plus the application, and backup, upgrade, and failure handling apply to each independently.
Ingestion is not limited to a live OpenTelemetry SDK. The README lists OpenTelemetry, Prometheus, Vector, FluentBit, and CloudWatch as ingestion sources. That matters for migration: a team with existing Prometheus scrapes or FluentBit log pipelines does not have to rewrite collection before getting value out of the UI. The README also notes Grafana compatibility, where Grafana is configured to use Uptrace as a Tempo or Prometheus datasource. That is a sensible escape hatch for teams that have standardised on Grafana dashboards and only want Uptrace as the storage and query layer.
Querying Spans and Metrics: Two Separate Languages
Uptrace does not expose one query interface. The README describes a SQL-like query language for aggregating spans and a PromQL-like language for aggregating metrics. Anyone who has worked with Prometheus will recognise the shape of the second; the first is closer to SQL than to any tracing UI's filter syntax.
Having two languages is a real cost. A dashboard that combines a span-derived number with a metric-derived number requires the author to hold both grammars, and the alerting rules inherit the same split. The compensating benefit is expressiveness: faceted filters and a query builder sit on top for interactive exploration, but the underlying languages let you write aggregations that a pure point-and-click interface would not support. The README links separate documentation pages for span querying and metric querying, which suggests the project treats them as distinct surfaces rather than pretending they are unified.
If your team has never written PromQL, budget time for the metrics side. If your team has never written SQL against spans, budget time for the traces side. Neither is learned from the README alone.
Running It: Docker Example First, Then the Getting Started Guide
The README's quickstart offers two paths. One is a cloud demo at app.uptrace.dev/play that requires no login. The other is running it locally with Docker, with the compose files living under example/docker in the repository. The README then points to the getting started guide at uptrace.dev/get for the actual configuration walkthrough.
That ordering is deliberate and worth following. The README itself does not publish the environment variables, ports, or config file schema. It states that users and projects can be managed via YAML config and that SSO is available through OpenID Connect with Keycloak, Google Cloud, and Cloudflare named as providers. Those are the features you will be configuring, but the concrete keys are in the linked documentation, not in the repository README. Treat the README as a feature inventory and the getting started guide as the installation manual.
One practical note on the Docker route: because the stack includes ClickHouse and PostgreSQL, the compose example is the fastest way to see the whole topology before you commit to a production layout. Whether that example is suitable for production is not something the README claims, and it should not be assumed.
The Beta Release Line and What It Means for Upgrades
The most recent releases are v2.1.0-beta.8, v2.1.0-beta.7, and v2.1.0-beta.6. The project is publishing beta versions of a 2.1 line, with the newest dated 2026-08-13. There is no stable v2.1.0 in the release list provided.
For an APM system that stores your production telemetry, that is the limitation to weigh hardest. Running beta software in the observability path means the tool you reach for during an incident is itself on a pre-release track. It does not mean the software is unusable, and the beta cadence between June and August suggests active work. It does mean upgrade planning has to account for schema or configuration changes between betas, and that the ClickHouse and PostgreSQL schemas underneath are part of that risk.
There is a second, quieter cost: the split storage model means an upgrade is not a single container swap. The application, the ClickHouse schema, and the PostgreSQL metadata all move together, and the README does not describe a migration procedure. Verify the upgrade path in the documentation before putting this in front of on-call engineers.
AGPL-3.0 and the Self-Hosted Boundary
Uptrace is licensed under AGPL-3.0. That is a stronger copyleft than the Apache-2.0 licence used by much of the OpenTelemetry ecosystem, and it is the constraint most likely to disqualify the project for a given team.
The AGPL's distinguishing feature is the network clause: offering the software's functionality to users over a network can trigger source disclosure obligations. For a team running Uptrace purely as internal infrastructure, this is usually unremarkable. For a company that wants to embed Uptrace's UI or query layer into a product it sells, or to offer it as a managed service, the licence needs a real review. This is not legal advice, and the exact boundary depends on how the software is combined and distributed. If the AGPL is a problem, the README's mention of Grafana compatibility is the relevant fact: Grafana can be pointed at Uptrace as a Tempo or Prometheus datasource, so the query and storage layer can be consumed through a separate front end.
Note also that the project is not archived and the last push is recent, so the licence terms are the live terms of an active codebase, not a frozen relic.
Where Uptrace Is the Wrong Tool
Uptrace assumes you have adopted OpenTelemetry, or are willing to. If your instrumentation is vendor-specific and you have no intention of standardising on OTLP, the ingestion integrations listed (Prometheus, Vector, FluentBit, CloudWatch) cover common cases but not every SDK, and the project's centre of gravity is clearly OpenTelemetry.
The second mismatch is operational appetite. A team that wants a single binary or a hosted endpoint with no database administration is not the audience. ClickHouse plus PostgreSQL is two systems to run, monitor, back up, and version. The README's performance claims are framed around a single server, which is attractive, but a single server running two databases is still two databases.
The third is release maturity. If your organisation requires stable, tagged releases for anything in the production observability path, the current beta line is a blocker until v2.1.0 ships as a stable tag.
A real alternative worth comparing on approach rather than features: SigNoz. It also targets OpenTelemetry-native APM with traces, metrics, and logs in one UI, but it stores data in ClickHouse only, without the separate PostgreSQL metadata layer that Uptrace describes. That difference is concrete. Uptrace's two-database split gives relational storage for mutable metadata like alerts and metric names; SigNoz's single-store design gives you one database to operate. Which is better depends on whether you value the relational metadata model or the smaller operational surface. Both carry copyleft considerations, and SigNoz's licence should be checked separately.
Editorial conclusion
Adopt Uptrace if you already emit OpenTelemetry data, want traces, metrics, and logs in one self-hosted UI, and are comfortable running ClickHouse and PostgreSQL alongside each other. Do not adopt it if AGPL-3.0 obligations are incompatible with your distribution model, or if you need a stable release rather than a beta line. Before committing, check the docker example under example/docker to confirm the compose layout, and read the getting started guide to verify that your existing OTLP endpoint can be repointed without a collector change.
Community notes