Skip to main content
Version: Nightly

Common Questions

How does GreptimeDB handle metrics, logs, and traces?​

GreptimeDB uses the same columnar engine and the same Tag, Timestamp, and Field column semantics for metrics, logs, and traces. The signals can use separate physical tables with different schemas, indexes, TTL settings, and ingestion paths.

All three signal types can be queried with SQL. Metrics also support PromQL, while traces have a separate Jaeger-compatible query API. Flow can continuously derive and materialize aggregates from source tables. See the Data Model, Logs, and Traces.

Does GreptimeDB support updates?​

Partially. For a table that uses deduplication, writing another row with the same primary key and time index updates Field values according to the table's merge_mode. The primary key and time index identify the row and are not updated in place.

For tables created with SQL, the default last_row mode keeps the latest row. The last_non_null mode keeps the latest non-null value for each Field. Auto-created tables can use protocol-specific defaults. Deduplication applies within a Region. GreptimeDB accepts any table column as a partition column, but for a deduplicating table, partition columns should be chosen from the primary key so rows with the same primary key remain in one Region and can be merged correctly. See Table Sharding.

Append-only tables disable deduplication, so repeated keys and timestamps create additional rows rather than updates. See Update Data and the merge_mode reference.

Does GreptimeDB support deletion?​

Yes, for tables that allow deletion. You can delete matching rows with SQL, truncate a table, or expire data with TTL. Append-only tables do not support row deletion. See Delete Data.

Can I set TTL or retention policy for different tables or measurements?​

Yes. TTL can be set at database or table level, and a table-level setting takes precedence. See Manage Data Retention with TTL Policies.

What are the compression rates of GreptimeDB?​

There is no single compression ratio. Results depend on schema width, value distribution, primary-key cardinality, repetition, SST format, indexes, and workload. Indexes can improve filtering while increasing storage and write cost. Measure with representative data and retention settings rather than applying a general ratio.

One published edge benchmark provides a concrete but workload-specific result: after writing 10 million TSBS rows on a Qualcomm SA8155P, GreptimeDB Edge used 87 MB and SQLite used 1,686 MB. This result applies to the tested Edge edition, schema, and configuration; it is not a general compression ratio for GreptimeDB deployments. See the GreptimeDB Edge and SQLite report.

For schema and index trade-offs, see the Schema Design Guide and Data Indexes.

How does GreptimeDB address the high cardinality issue?​

High cardinality still has a cost: more distinct primary-key values can increase metadata, index, memory, and query work. GreptimeDB provides several controls:

  • The flat SST format reduces per-series overhead and is the default for new tables. It is recommended for high-cardinality primary keys. The Flat Format engineering article explains its memtable and merge-path design and includes benchmark conditions.
  • Inverted, full-text, and skipping indexes can be added where their selectivity and storage cost fit the query workload. Indexing every column is usually unnecessary.
  • Append-only tables skip deduplication work when records are immutable and do not need updates or deletes.
  • Table partitioning distributes Regions across Datanodes in a cluster, but partition design and load distribution still matter.
  • Schema design should keep identifiers in the primary key only when they are used for grouping, deduplication, or filtering.

There is no universal cardinality limit that applies to every schema and deployment. Test expected series counts, write rates, query predicates, and retention together. See sst_format, Data Indexes, and the Schema Design Guide.

Does GreptimeDB support continuous aggregate or downsampling?​

Yes. Flow continuously computes over source-table data as new rows arrive and materializes the results in a sink table. It can implement fixed-window aggregation and downsampling while retaining the source data under its own TTL.

Can I store data in object storage in the cloud?​

Yes. Persistent data files can be stored in Amazon S3, Google Cloud Storage, Azure Blob Storage, Alibaba Cloud OSS, and supported S3-compatible services. Object storage is separate from WAL, metadata, and local cache; each has its own durability and recovery role. See Storage Location and Storage Options.

How is GreptimeDB's performance compared to other solutions?​

Performance depends on workload, schema, indexes, retention, hardware, object storage, cache, concurrency, and query shape. Use benchmark results only with their test conditions and compare them with your own expected workload.

Published reports include:

Does GreptimeDB have disaster recovery solutions?​

GreptimeDB provides the components needed to build a recovery plan, but object storage alone is not a complete solution. Persistent data files, WAL, Metasrv metadata, Region placement and failover, and deployment configuration each affect recovery point and recovery time objectives.

Cluster failover also depends on a correctly configured topology and healthy replacement Datanodes. Back up and test metadata and WAL recovery alongside object-store policies. See Disaster Recovery, WAL Overview, and Storage Location.

Does GreptimeDB support geospatial computation?​

Yes. GreptimeDB provides SQL functions for WKT values, Geohash, H3, S2, spatial relationships, distance, and area. These functions do not create or imply a separate database spatial index. See Geospatial Functions.

Any JSON support?​

GreptimeDB provides two JSON column types:

  • The experimental JSON type stores general JSON values and works with JSON functions.
  • JSON2, available since v1.2 and currently Beta, stores subpaths in a structured columnar form for logs and other semi-structured data. It supports dot-path access, json_get, and optional type hints. JSON2 currently requires an append-only table.

Neither type currently provides index options for JSON subpaths. Put stable, frequently filtered attributes in typed columns when they need inverted, full-text, or skipping indexes. See Data Indexes.

More Questions?​

For deployment, migration, operations, and schema questions, see the full FAQ.