Three systems, three query languages.
Unified observability should be one workflow.
Victoria Stack is a set of open-source components from VictoriaMetrics: VictoriaMetrics (metrics), VictoriaLogs (logs), and VictoriaTraces (distributed tracing). While it follows the Victoria ecosystem's performance and cost-efficiency principles for each signal, you still operate multiple systems and multiple query languages (PromQL/MetricsQL, LogQL, and trace queries). For teams that want a single ingestion and query surface across metrics, logs, and traces, GreptimeDB provides an unified observability database backed by SQL + PromQL.
VICTORIA STACK
Metrics + logs + traces are separated across stores and tooling
PromQL/MetricsQL for metrics, LogQL for logs, trace backend for traces
Different UIs and operational surfaces per signal
Cross-signal correlation requires joining data outside the engine
More components to scale and keep in sync
GREPTIMEDB
One engine for ingest, storage, and query across signals
SQL + PromQL on top of unified storage
Query metrics, logs, and traces together in one place
Compute-storage disaggregation with native object storage
Scale stateless compute independently
Scaling Victoria means scaling multiple components - and keeping separate pipelines aligned.
3 SYSTEMS
metrics storage + PromQL
log ingestion + LogQL
trace ingestion + OTLP/Jaeger
signal-specific workflows
1 ENGINE
one endpoint for all signals
scale out quickly
compute-storage disaggregation
| Feature/Aspect | GreptimeDB | Victoria Stack (VictoriaMetrics + VictoriaLogs + VictoriaTraces) |
|---|---|---|
| Data Model | Unified Observability Database | Separate stores per signal |
| Multi-model Support | Metrics, Logs & Traces in one database engine | Metrics + logs + traces with multiple components |
| Query Experience | SQL + PromQL, unified query surface | PromQL/MetricsQL for metrics, LogQL for logs, trace queries in a separate backend |
| Ingestion Protocols | SQL, gRPC, OpenTelemetry, and observability-compatible ingestion across signals | Signal-specific ingest and endpoints |
| Storage Architecture | Compute-storage disaggregation with native object storage | Separate storage per component (metrics/logs/traces) |
| Retention & Tiering | Flexible TTL policies with automatic tiering | Retention and cleanup per component |
| Operational Complexity | One operational surface with fewer moving parts | More components to operate and keep consistent across signals |
| Cross-signal Correlation | Native correlation in one engine | Correlation typically requires external pipelines or tooling |
Unify metrics, logs, and traces without rewriting your whole observability stack.
Switch your metrics remote write / remote storage target to GreptimeDB. PromQL dashboards keep working while you consolidate.
30 min
Route your log stream (Loki Push API / HTTP ingest / compatible endpoints) into GreptimeDB.
1 hour
Bulk import historical metrics, logs, and traces into GreptimeDB while live ingestion continues.
1-3 days
After validation, shut down VictoriaMetrics, VictoriaLogs, and VictoriaTraces one by one.
2 Weeks
Side-by-side feature breakdowns for additional alternatives.
Stay in the loop
Get the latest updates and discuss with other users.
