# openGemini/openGemini

CNCF sandbox project, an open source distributed time-series database with high concurrency, high performance, and high scalability

Repository: https://github.com/openGemini/openGemini
Canonical: https://ross.abutalabs.com/products/opengemini
Homepage: https://www.opengemini.org
Language: Go
License: Apache-2.0
License Family: permissive
Topics: distributed, devops, iot, time-series-database, cloudnative, observability
Last push: 2026-09-03T01:23:38+00:00

## Health v2 (maintenance only)
Score: 84/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 100, release rhythm 53, longevity 100
- inputs: {"age_days": 1528, "days_push": 0, "days_rel": 233, "gap_med": 67.0, "n_releases_24m": 7}
- flags: none
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 1172, forks 176 (observed 2026-09-03T02:15:15.732764+00:00)

## What it is
openGemini is a cloud-native distributed time-series database written in Go, designed for storing and analyzing massive telemetry data such as metrics, logs, and traces. It is a CNCF sandbox project that emphasizes high performance, high scalability, and high cardinality support for observability workloads.

## Use cases
- store and query massive telemetry data for observability
- handle high cardinality time-series data without excessive index memory usage
- deploy a distributed time-series database cluster that scales horizontally
- replace InfluxDB with better write performance and compression
- collect and analyze metrics, logs, and traces for system troubleshooting
- run a self-hosted time-series database for IoT sensor data

## When to choose
- you need a distributed, horizontally scalable time-series database for observability or IoT workloads
- your data has high cardinality that overwhelms traditional time-series databases
- you want strong data compression (15:1 or higher) to reduce storage costs
- you prefer a cloud-native, CNCF-backed project with no third-party dependencies
- you need faster write performance than InfluxDB for time-series ingestion

## When to avoid
- you need a simple single-node embedded time-series store for a small application
- your workload is relational with complex joins rather than time-series data
- you require a fully managed cloud database service rather than self-hosted deployment
- your team depends on a mature ecosystem with extensive third-party tooling beyond observability

## Facets
- artifact type: service
- maturity: active
- function: database, monitoring, analytics, streaming
- domain: databases, monitoring, iot, big-data, time-series
- platform: cloud, self-hosted, go
- tags: time-series-database, observability, distributed-database, cncf-sandbox, high-cardinality, influxdb-compatible, lsm-storage, mpp-architecture, telemetry-data, columnar-storage, devops, linux, docker, kubernetes

## Member repositories
- openGemini/openGemini (main) score 84

## Provenance
- Observed fields: from GitHub, fetched 2026-09-03T02:15:15.732764+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-30T06:28:24.240667+00:00, confidence not recorded.
  - readme: https://github.com/openGemini/openGemini (fetched 2026-09-03T02:15:15.732764+00:00, sha 60236ae0318d)
  - homepage: https://www.opengemini.org (fetched 2026-08-29T12:33:39.196192+00:00, sha 2c0f2ee93cc4)
- Data as of 2026-08-30T08:39:29.467469+00:00.