Scale observability on your infrastructure

Usually when you need a capability the open-source build does not have:

• Read/write isolation — heavy analytical queries are slowing down ingestion, and you want them on separate nodes.
• Independent read capacity — you need to add read throughput without duplicating storage or adding write load. That is what read replicas do.
• Automated cluster operations — Repartition, Region migration, and indexing are all available in open source, but you are running them by hand and want them automated.
• Higher write throughput — bulk ingestion on Prometheus Remote Write and gRPC.
• Security and compliance — LDAP, RBAC, audit logging, encryption in transit and at rest.
• Operations and support — the management console (cluster overview, Region management, slow-query analysis) and SLA-backed one-on-one support.

If none of these apply, the open-source build is enough — it is the same engine.

Enterprise adds capabilities across seven areas:

• Performance: bulk ingestion (up to 5× write throughput on Prometheus Remote Write and gRPC), smart tiered caching (3 to 5× query speedup).
• Autopilot: auto repartition, region load balancer, datanode groups for read/write isolation, remote compaction and indexing (around 20% to 30% infra cost reduction).
• Reliability: read replicas with near-zero-cost manifest sync, active-active failover.
• Observability: SQL-native triggers (compatible with Prometheus Alertmanager), management console, performance diagnostics.
• Security: LDAP, RBAC, audit logging, encryption in-transit and at-rest.
• Compatibility: Elasticsearch and Kibana QueryDSL backend.
• Support: one-on-one expert assistance, SLA-backed response times by severity.

For the full open-source vs Enterprise comparison, see feature comparison.

Three models. All run the same Enterprise binary with the same APIs — they differ in where the data lives and who runs the cluster.

• On-premises: GreptimeDB runs in your data center or private cloud. Your team operates it; Greptime provides support, upgrade guidance, and a custom SLA.
• BYOC: GreptimeDB runs in your own AWS, Azure, or GCP account, so data and storage stay under your cloud contract. Greptime handles day-to-day operations — deployment, upgrades, monitoring, and incident response — within the boundary you grant.
• Fully managed: Greptime runs the cluster in Greptime's cloud account and bills by usage. You operate nothing.

If regulatory or data-residency rules require the data to stay in your environment, on-premises and BYOC both satisfy that; BYOC additionally offloads operations. Talk to an engineer to work out which fits.

The fully-managed dedicated tier starts at $290/month, billed by node configuration (vCPU and memory) plus object storage and cache usage. BYOC and on-premise are custom-priced based on cluster size and SLA. See the pricing page for the full tier breakdown, or contact us for a quote.

Enterprise comes with SLA-backed response times by severity, one-on-one technical support, system-level performance diagnostics, and customization for specific deployment scenarios. Larger contracts add named support engineers and a regular architecture review. Open-source users get community support via Slack and GitHub.

Yes. Li Auto runs GreptimeDB Enterprise on-vehicle across its EV production fleet to capture raw telemetry and save tens of millions in cloud bandwidth costs (case study). OceanBase Cloud runs 80+ GreptimeDB Enterprise clusters with 300TB+ of logs and SQL audit data after migrating off Grafana Loki (case study). Other deployments include automotive OEMs, a Fortune 500 retailer, AI infrastructure, and industrial IoT. See Use Cases for more.