GreptimeDB

Use it when

• Metrics, logs, and traces should land in one store instead of Prometheus beside Loki beside a trace backend.
• Object storage as the primary store is the cost model you want, with compute and storage scaling separately.
• The data will be asked both PromQL and SQL: dashboards keep PromQL, analysts get SQL, and OpenTelemetry feeds it natively.
• Edge-to-cloud deployment matters; the same Rust engine runs small.

Think twice when

• You need general-purpose OLAP over business tables; the engine is tuned for observability's filter-and-aggregate shape, not wide joins.
• Rows must update in place; inserts overwrite by key and timestamp instead.
• Maturity is the test: it is younger than ClickHouse and the observability incumbents it proposes to replace.

How it runs

Stateless frontends speak SQL, PromQL, MySQL, PostgreSQL, Prometheus remote write, and Jaeger; datanodes own table regions and flush memtables as SSTs to S3, Azure Blob, or GCS with local cache. Run it standalone or clustered; GreptimeCloud is the managed service.