GreptimeDB vs. Victoria Stack

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

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

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 separation with native object storage
Scale stateless compute independently

Victoria Stack

3 SYSTEMS

VictoriaMetrics

metrics storage + PromQL

VictoriaLogs

log ingestion + LogQL

VictoriaTraces

trace ingestion + OTLP/Jaeger

Separate UIs

signal-specific workflows

GreptimeDB

1 ENGINE

Unified ingest gateway

one endpoint for all signals

Stateless compute nodes

scale out quickly

Native object storage

compute-storage separation

SQL + PromQL in the same query experience
Metrics + Logs + Traces under one engine
Scale compute and storage independently

Feature comparison

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 separation 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

Redirect metrics ingest

Switch your metrics remote write / remote storage target to GreptimeDB. PromQL dashboards keep working while you consolidate.

30 min

Redirect log ingestion

Route your log stream (Loki Push API / HTTP ingest / compatible endpoints) into GreptimeDB.

1 hour

Backfill history

Bulk import historical metrics, logs, and traces into GreptimeDB while live ingestion continues.

1-3 days

Decommission the Victoria stack

After validation, shut down VictoriaMetrics, VictoriaLogs, and VictoriaTraces one by one.

2 Weeks

OceanBase

Staff Engineer

Learn more

Migrating from Loki to GreptimeDB enables high-performance querying of massive log data at scale, offers multi-cloud deployment flexibility, and significantly simplifies application and deployment architecture.