What it does
GreptimeDB is a columnar database built for observability data. It accepts metrics, logs, and traces through common telemetry protocols, stores them in a shared table model, and supports SQL and PromQL queries. It can run as a local process or in a distributed deployment, with object storage used for long-term data. This is a database and query layer for telemetry, not a complete incident-management workflow; teams still need to choose their collectors, dashboards, and operating model.
Follow the quick start with sample telemetry
The official quick start asks you to install and start a GreptimeDB instance, then connect with a MySQL or PostgreSQL client, or open the built-in dashboard on port 4000. Its sample exercise creates tables for latency measurements, application logs, and traces, inserts example rows, and uses SQL to find a latency percentile and correlate the three signals. The examples are documentation, not a workload we ran.
A useful first task is to send a small set of OpenTelemetry data from an existing collector, then query it in SQL and check whether the dimensions needed for investigations are present. GreptimeDB also documents Prometheus remote write, Loki push, Elasticsearch bulk ingestion, and PromQL. Existing collectors can therefore be evaluated one signal at a time rather than replacing an entire telemetry pipeline on day one.
The engine is published under Apache 2.0. A self-hosted instance gives control over where the data lives, but it also makes deployment, retention, and storage configuration the operator's responsibility. The project describes Enterprise capabilities separately from its open-source engine. Its pricing page says the Apache-2.0 core is free to run in your own environment and separately lists managed Enterprise and bring-your-own-cloud offers. A managed monthly starting rate is shown, but currency, region, and commitment details are not specified here, so no exact amount is repeated.
Check the local security default
The quick-start guide says authentication is disabled by default for a local instance. Treat that as a development convenience, not a production-ready security posture: configure access controls before exposing the service beyond a trusted local environment. The docs also describe multiple interfaces and protocols, so confirm that the ingestion and query paths your team uses are supported before planning a migration.
Strengths
- Metrics, logs, and traces share one database model, enabling cross-signal SQL queries.
- The documented interface set includes OpenTelemetry, Prometheus remote write, SQL, and PromQL.
Watch out for
- Authentication is disabled by default in the local quick-start configuration, so exposed deployments need deliberate security configuration.
- Self-hosted deployments require the team to choose and operate the database infrastructure and retention setup.
Best for
- Teams evaluating a single store for metrics, logs, and traces
- Querying telemetry with SQL while retaining Prometheus-compatible workflows
Sources
- GreptimeDB: Open-Source Observability Database (Oct 25, 2026)
- GreptimeDB Documentation (Oct 25, 2026)
- Quick Start (Oct 25, 2026)
- greptimedb LICENSE (Oct 25, 2026)
- Greptime Pricing (Oct 25, 2026)