DataBuff: an AI-native APM backend that speaks OTLP on 4317 and 4318

What DataBuff is for, and who it is not for

The README states the mission plainly: build the strongest OpenTelemetry APM backend. That framing matters because it tells you what the project is competing with. Not a general observability suite, but the storage and query layer behind OTLP, with an AI layer on top that reads live telemetry instead of a cached summary. The target reader is an SRE or platform engineer who already has OpenTelemetry instrumentation in place and wants a self-hosted backend plus something that closes the loop from alert to root cause.

The repository layout reflects that scope. There is ai-apm-ingest for ingestion, ai-apm-web for the server side, ai-apm-frontend for the UI, ai-apm-common for shared code, ai-apm-demo for sample traffic, plus deploy/, docs/ and integrations/. Java is the primary language. The project is listed on the OpenTelemetry vendor page as a native OTLP vendor and on the CNCF Landscape, per the README.

The wrong audience is equally clear. If your services are not instrumented and you have no appetite for adding OpenTelemetry SDKs or an eBPF agent, DataBuff has nothing to ingest. The eBPF APM path is described as kernel-level and non-intrusive, which lowers that barrier, but the README does not state which kernels or distributions it covers, so treat it as unverified for your fleet.

One more boundary: the AI features are not self-contained. The README says you add an API key after install to enable AI. Without a reachable model endpoint, you have an APM backend with topology and RED metrics but no multi-agent troubleshooting.

How ingestion and the three-component stack fit together

The architecture diagram in the README shows three components: Ingest, Doris, and Web. Ingest receives telemetry, Doris stores it, Web serves queries and the UI. There is no Kafka, no separate alerting daemon, no metadata store listed in the minimal diagram, which is the point of the "no middleware sprawl" claim in the feature list.

The protocol table is the most concrete part of the README. OTLP arrives over gRPC on port 4317 and HTTP on port 4318, carrying traces, metrics and logs. SkyWalking's native gRPC protocol is accepted on port 11800 for traces, JVM metrics and logs. The README says migration between the two is a matter of changing the exporter address, which is a plausible claim given that both endpoints terminate in the same ingest service, though the project does not document how signal naming or attribute mapping differs between the two paths.

Above the storage layer sits the AI Brain, described as orchestrating query, inspection, ops, and Q&A experts in parallel. The README shows a roadmap arc running Visible, Legion, Inspect, Diagnose, Repair, Predict, Answer, and labels the AI application observability items (LLM call chains, token analytics, agent topology, skill/tool/model tracing) as roadmap rather than shipped. That distinction is worth holding onto: the multi-agent troubleshooting is presented as available now, the LLM observability is not.

MCP is described as working in both directions. DataBuff exposes capabilities to Cursor or Claude, and can ingest external MCPs such as Prometheus. The README does not document the MCP server configuration keys, so plan on reading docs/README_en.md before wiring that up.

Installing DataBuff and connecting a model

The README gives a five-minute quick start. The first command launches Ingest, Doris and Web together. It pipes a remote script into bash, so if your policy forbids that, download the script first and read it before running.

curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

After this completes, the UI is expected at port 27403 on the host. The README gives the default credentials as admin / Databuff@123. Change that password before the host is reachable from anywhere you do not control.

An optional second command installs a demo workload that reports traces, which is the fastest way to see topology and service lists populated without touching your own services.

curl -fsSL https://databuff.ai/databuff/ai-apm-demo-install.sh | bash

For hosts without outbound internet, the README points to the install page for an offline bundle and gives this sequence. The version and architecture appear in the archive name, so substitute the values you downloaded.

tar -zxvf databuff-ai-apm-offline-<version>-<arch>.tar.gz
cd databuff-ai-apm-offline-<version>-<arch> && sudo ./install.sh

The README also mentions a Kubernetes install path, but the snippet is truncated in the published README, so the exact manifest URL and flags are not verifiable from the repository front page.

Once the platform is up, open http://YOUR_HOST:27403, log in, and add an API key for a model. The README names Kimi, DeepSeek, GLM, Ollama and other OpenAI-compatible APIs as supported providers. Release v0.1.9 mentions LLM provider CRUD and credential hardening, so provider management is a first-class screen rather than an environment variable. Point your existing OpenTelemetry exporter at port 4317 or 4318 and data should appear in the service list.

Where DataBuff is the wrong tool

The version number is the first honest constraint. The latest release at the time of writing is v0.1.9, dated 2026-09-07, preceded by v0.1.8 and v0.1.7 within roughly five weeks. That cadence is a good sign for momentum and a bad sign for interface stability. Anything you script against the API, the MCP surface, or the model provider configuration should be expected to move.

Upgrade and rollback are the second gap. The README documents install, offline install and a Kubernetes path, but it does not document how to upgrade an existing deployment, how to migrate the Doris schema between versions, or how to roll back if an upgrade fails. For a system holding your traces and metrics, that is the question to raise with the maintainers before production, not after.

The AI layer adds a dependency the rest of the stack does not have. A self-hosted APM that talks to an external model API has an outbound network dependency and a data-egress question: telemetry summaries leave your network. The README does not describe what gets sent to the model, whether prompts are redacted, or whether a fully local model through Ollama keeps everything on-premises. Ollama is listed as supported, which suggests the local path exists, but the README does not state that no data leaves the host in that configuration.

Finally, the AI application observability features are roadmap items. If your reason for evaluating DataBuff is LLM call chains and token analytics, the README places those in the roadmap, not in the shipped feature set. The released notes for v0.1.8 mention GenAI Trace Unicode handling, which implies some GenAI trace support exists, but the README does not describe it as a finished capability.

DataBuff against a plain OpenTelemetry collector plus a store

The obvious alternative is the one most teams already run: an OpenTelemetry Collector writing to a time-series or trace store, with a separate dashboard. The difference in approach is where the intelligence lives. In that setup, the collector routes and samples, the store holds data, and the human writes the query. DataBuff puts a query layer and a set of agents between the data and the human, so the entry point is a natural-language question such as which service was slowest, and the answer comes from live telemetry rather than a pre-built dashboard.

That is a real architectural difference, not a packaging one. A collector-plus-store stack gives you full control over retention, sampling and query language, and it composes with whatever alerting you already have. DataBuff gives you a smaller set of components and a shorter path from question to answer, at the cost of a fixed storage engine (Doris), a fixed UI, and an AI layer whose behaviour depends on an external model.

There is a middle option worth naming: keep your collector, send a copy of the OTLP stream to DataBuff on 4317 or 4318, and run it alongside your existing backend. Because ingestion is OTLP-native, this is a fan-out, not a migration. You get the topology and AI troubleshooting without giving up the store your team already knows. The cost is running Doris and the DataBuff services in addition to what you have.

SkyWalking users have a third path. The README states the ingest accepts SkyWalking native gRPC on 11800, so an existing SkyWalking agent can report to DataBuff by changing the exporter address. That is a lower-effort evaluation than re-instrumenting, though the README does not document which SkyWalking agent versions are supported beyond the v0.1.9 release note mentioning SkyWalking 8.x gRPC.

Licence, maintenance and the cost of staying current

The repository states AGPL-3.0. The README's badge says Apache-2.0, which is a discrepancy you should resolve with the maintainers rather than assume away; the LICENSE file and the repository metadata both point to AGPL-3.0, and AGPL-3.0 is the more restrictive of the two. For internal use the practical difference is small. For a product where you modify DataBuff and expose it over a network, AGPL-3.0's source-availability obligation is the part your legal review needs to see. The repository also carries NOTICE, THIRD-PARTY-NOTICES.txt and SOURCE-OFFER.txt at the top level, which suggests the project has thought about third-party attribution and source offers. None of this is legal advice; read the licence text.

On maintenance, the last push to the default branch was on 2026-09-16, and the repository is not archived. Three releases landed between 2026-08-10 and 2026-09-07. By the evidence in the repository, the project is being worked on now.

The upgrade cost is the part the README does not settle. There is no documented migration procedure between v0.1.7, v0.1.8 and v0.1.9, and no documented rollback. The offline bundle naming includes a version and an architecture, which means each upgrade is a new bundle download and a re-run of install.sh. Whether that preserves existing data in Doris is not stated. If you deploy this, keep the bundle archives and take a Doris backup before each upgrade, and confirm the data-preservation behaviour with the maintainers first.

Editorial conclusion

Adopt DataBuff if you already emit OTLP and want a self-hosted backend with AI troubleshooting in the same stack, and if AGPL-3.0 fits how you ship software. Do not adopt it if you need a documented upgrade and rollback path or a stable API: at v0.1.9 the project is still at 0.1.x. Verify three things before you commit: that the install script downloads a bundle you can archive for offline reinstall, that your model provider is reachable from the host, and that your legal review accepts AGPL-3.0 for a network-facing service.

Frequently asked questions

Official sources

1. databufflabs/databuff on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases