一个引擎，统一处理指标、日志和链路

公开 benchmark 里，GreptimeDB 写入吞吐约是 InfluxDB 的 2 倍、TimescaleDB 的 2.17 倍，时间范围扫描查询最快 67 倍，相同数据集存储只占 1/18。日志场景下，写入比 Loki 快 1.5 倍，查询快 40 到 500 倍，存储约为 ClickHouse 的 50%、Elasticsearch 的 12.7%。详细方法和数据见性能报告博客和竞品对比页。

可以。GreptimeDB 支持通过 OpenTelemetry OTLP、Prometheus Remote Write、Loki Push 和 Elasticsearch Bulk 写入数据，并通过 Jaeger 查询 API 查询链路。三类信号都由同一个列式存储引擎处理，并采用统一的表模型——Tag 列、Timestamp 列和 Field 列；当数据包含共同标识符时，可以通过一条 SQL 关联不同信号，无需 ETL。详见 Why GreptimeDB 和集成概览。

不是。集群部署、对象存储、用于持续聚合的 Flow 引擎以及各种写入协议都包含在 Apache-2.0 的开源版本中。企业版增加的是运维和规模方面的能力：读副本、工作负载隔离、自动重分区与 Region 负载均衡、批量写入、LDAP/RBAC 和审计日志、企业管理控制台、SLA 保障的技术支持，以及 Elasticsearch QueryDSL 兼容。核心引擎和 API 与开源版一致。查看完整功能对比。

两种：单机部署（单个二进制，可运行在 Linux、macOS 和 ARM 设备上）和 Kubernetes 集群部署（存算分离，数据放在对象存储上）。同一个二进制支持从单节点扩展至百节点集群。生产环境存储建议使用 S3、GCS 或 Azure Blob，集群元数据可使用 etcd、MySQL 或 PostgreSQL。安装步骤见安装指南。端边云场景请参考端边云一体解决方案。

• 写入：OpenTelemetry OTLP、Prometheus Remote Write、InfluxDB 行协议、Loki Push、Elasticsearch Bulk、MySQL、PostgreSQL、gRPC。
• 查询：SQL、PromQL、Jaeger 查询 API。
• SDK：Go、Java、Rust、Erlang、.NET、TypeScript，以及任意 OpenTelemetry SDK 或 MySQL/PostgreSQL 驱动。
• Grafana：官方插件、Prometheus 数据源、MySQL 数据源。

兼容性按协议分别成立，查询侧的覆盖范围小于写入侧：

• Loki：仅兼容 Push 写入，不支持 LogQL。
• Elasticsearch：_bulk 写入在开源版中提供，且只支持插入；QueryDSL 兼容由企业版提供，且为部分兼容。
• Prometheus：写入使用 Remote Write，查询使用 PromQL。
• Jaeger：链路查询 API。

各协议接入指南见数据写入。

公开案例：理想汽车 把 GreptimeDB 部署在车端，覆盖百万级量产车队采集原始遥测数据，云端带宽成本省下数千万；OceanBase Cloud 跑 80+ 个 GreptimeDB 集群，承载 300TB+ 日志和 SQL 审计数据，从 Grafana Loki 迁过来后存储成本降了 60% 以上。一家头部 AI 公司的 GreptimeDB 集群规模超过 6000 核，保存 40TB 数据，统一承载其 Spark 大数据平台的监控和日志。其他行业还包括电商可观测、AI 基础设施、工业物联网，更多见用户案例。