GreptimeDB v0.12 focuses on indexing improvements and comprehensive optimizations to the Metric Engine, alongside performance and feature enhancements. This release lays a solid foundation for the upcoming key update, v0.13, in GreptimeDB’s 2025 roadmap.

Between v0.11 and v0.12, the Greptime team has made significant progress, merging 125 PRs, including 47 feature enhancements, 41 bug fixes, 7 code refactorings, 6 performance optimizations, and numerous test improvements. During this period, 3 individual contributors made 17 contributions.

A big thank you to the team and all individual contributors! We welcome more developers interested in database technology to join us.

Indexing Improvements

Introducing Skipping Index

The newly added Skipping Index significantly reduces storage space consumption, making it ideal for scenarios requiring high ingestion throughput or storage efficiency. While it may introduce minor performance overhead for some queries, its storage and computation cost benefits are evident. We particularly recommend using the Skipping Index for the trace_id field in traces.

Unified Index Creation Syntax

This update unifies the syntax for inverted indexes, skipping indexes, and full-text indexes, resolving previous inconsistencies. Now, users can define different types of indexes through column constraints and modify existing indexes via ALTER statements.

Example syntax:

CREATE TABLE IF NOT EXISTS system_metrics (
    host STRING INVERTED INDEX,
    idc STRING SKIPPING INDEX,
    cpu_util DOUBLE,
    memory_util DOUBLE,
    disk_util DOUBLE,
    desc1 STRING,
    desc2 STRING FULLTEXT INDEX,
    ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY(host, idc),
    TIME INDEX(ts)
);

Index modifications via ALTER:

ALTER TABLE table_name MODIFY COLUMN column_name SET SKIPPING INDEX WITH(granularity = 1024, type = 'BLOOM');
ALTER TABLE table_name MODIFY COLUMN column_name UNSET SKIPPING INDEX;

Metric Engine Enhancements

Performance Optimizations

• Sparse Primary Key Encoding (Experimental, disabled by default): In metrics-based scenarios, encoding speed has increased by over 3x.
• Table Batch Creation Optimization: When writing metrics data via Prometheus Remote-Write, GreptimeDB automatically creates a large number of tables on first ingestion. v0.12 reduces table creation time from minutes to seconds, significantly minimizing write-time latency.
• DROP DATABASE Performance Boost: The execution speed of this operation has significantly improved, reducing database deletion time from minutes to seconds.

PromQL Compatibility Enhancements

GreptimeDB now fully supports Kubernetes-related monitoring dashboards, with specific improvements including:

• Fixing unexpected behaviors in nested and / unless / or operators.
• Supporting on and ignoring vector matching.
• Adding support for sort_desc, sort, sort_by_label, and sort_by_label_desc functions.
• Fixing value escaping issues.
• Enabling subqueries.
• Enhancing query error reporting for a better user experience.

Breaking Changes

• GreptimeDB no longer supports the Interval column type.
• DateTime Type Adjustment: The native DateTime type is deprecated and now serves as an alias for Timestamp(6).
• Unified index creation syntax.
• Updates to startup parameters and configuration files—please refer to the v0.12 upgrade docs for necessary adjustments.

Additional Enhancements

Enhanced ALTER TABLE Functionality

GreptimeDB now supports adding multiple columns in a single ALTER TABLE statement:

CREATE TABLE alter_test(i INTEGER, j TIMESTAMP TIME INDEX);
ALTER TABLE alter_test ADD COLUMN "foo" STRING default 'foo' PRIMARY KEY, ADD COLUMN "bar" STRING default 'bar';

Also, the ALTER syntax now allows setting/unsetting indexes (as shown in the earlier Indexing section).

New Election Component Based on PostgreSQL in Metasrv

Metasrv now abstracts its metadata storage and election components, enabling support for multiple backends. Previously, only an Etcd-based backend was available. With v0.12, a PostgreSQL-based KvBackend and election component have been introduced, providing users with a robust alternative for large-scale metadata storage and enhanced system stability.

Performance Gains

TSBS Benchmark Results

Compared to v0.11, GreptimeDB v0.12 has demonstrated significant performance improvements, with a ~40% increase in ingestion rate and 30%~40% improvement in most query performances.

More details: https://github.com/GreptimeTeam/greptimedb/blob/main/docs/benchmarks/tsbs/v0.12.0.md

Test Environment (Amazon EC2)

Machine	c5d.2xlarge
CPU	8 core
Memory	16GB
Disk	100GB (GP3)
OS	Ubuntu Server 24.04 LTS

Ingestion Performance

Environment	v0.12 Ingest rate (rows/s)	v0.11 Ingest rate (rows/s)
EC2 c5d.2xlarge	326839.28	234620.19

Query Performance

Query type	v0.12 (ms)	v0.11 (ms)
cpu-max-all-1	12.46	14.75
cpu-max-all-8	24.20	30.69
double-groupby-1	673.08	987.85
double-groupby-5	963.99	1455.95
double-groupby-all	1330.05	2143.96
groupby-orderby-limit	952.46	1353.49
high-cpu-1	5.08	8.24
high-cpu-all	4638.57	5312.82
lastpoint	591.02	576.06
single-groupby-1-1-1	4.06	6.01
single-groupby-1-1-12	4.73	7.42
single-groupby-1-8-1	8.23	10.20
single-groupby-5-1-1	4.61	6.70
single-groupby-5-1-12	5.61	8.72
single-groupby-5-8-1	9.74	12.07

Log Storage Benchmark Report

A detailed benchmark report for log storage scenarios will be released in the coming days. Stay tuned for updates on our official blog.

Upgrade Guide

Before upgrading to v0.12, it is recommended to first upgrade GreptimeDB to v0.11. Refer to the v0.11 upgrade guide for more details.

The data format in the latest version is fully compatible with v0.11.x, meaning users do not need to export or import data. However, there are several major breaking changes between v0.11.x and the latest version, and some manual actions are recommended for upgrading your GreptimeDB instance. The main breaking changes include:

Configuration Changes

The default read/write cache paths have been changed to:

• Read cache path: ${data_home}/cache/object/read
• Write cache path: ${data_home}/cache/object/write
• cache_path now only sets the root directory of the cache. The default value is ${data_home}. It is recommended to let GreptimeDB manage the cache path automatically.
• Some experimental write cache configuration options have been promoted to official settings.

Previous write cache configuration:

[[region_engine]]
[region_engine.mito]
enable_experimental_write_cache = true
experimental_write_cache_size = "10G"
experimental_write_cache_ttl = "8h"
experimental_write_cache_path = "/path/to/write/cache"

Now it should be changed to:

[[region_engine]]
[region_engine.mito]
write_cache_size = "10G"
write_cache_ttl = "8h"
# No need to manually set write_cache_path.
# write_cache_path = "${data_home}"

gRPC Configuration Changes

In v0.12, it has been changed to:

## The gRPC server options.
[grpc]
## The address to bind the gRPC server.
bind_addr = "127.0.0.1:3001"
## The address advertised to the metasrv, and used for connections from outside the host.
## If left empty or unset, the server will automatically use the IP address of the first network interface
## on the host, with the same port number as the one specified in `grpc.bind_addr`.
server_addr = "127.0.0.1:3001"

This update includes two key changes:

• addr -> bind_addr, which specifies the gRPC server binding address.
• hostname -> server_addr, which is the address broadcasted to other nodes, allowing external connections to the current node.

⚠️ These changes aim to ensure a clear and consistent configuration structure.

Manual Index Creation

Starting from v0.12, inverted indexes are decoupled from primary keys and will no longer be automatically created. If needed, they must be created manually. Please note this change to avoid query performance degradation. The manual index creation method is as follows:

ALTER TABLE `cpu` MODIFY COLUMN `region` SET INVERTED INDEX;
SHOW INDEX FROM `cpu`;
+-------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+-----------------------------------------------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name                | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type                                          | Comment | Index_comment | Visible | Expression |
+-------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+-----------------------------------------------------+---------+---------------+---------+------------+
| cpu   |          1 | PRIMARY                 |            1 | hostname    | A         |        NULL |     NULL |   NULL | YES  | greptime-primary-key-v1                             |         |               | YES     |       NULL |
| cpu   |          1 | PRIMARY, INVERTED INDEX |            2 | region      | A         |        NULL |     NULL |   NULL | YES  | greptime-primary-key-v1, greptime-inverted-index-v1 |         |               | YES     |       NULL |
| cpu   |          1 | TIME INDEX              |            1 | ts          | A         |        NULL |     NULL |   NULL | NO   |                                                     |         |               | YES     |       NULL |
+-------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+-----------------------------------------------------+---------+---------------+---------+------------+

Unified Index Creation Syntax in CREATE TABLE

In v0.12, the CREATE TABLE statement syntax has been modified to enforce column constraints when creating inverted, skip-list, and full-text indexes. The INDEX keyword must be specified after the index type.

New syntax example:

CREATE TABLE IF NOT EXISTS `logs` (
  message STRING NULL FULLTEXT INDEX WITH(analyzer = 'English', case_sensitive = 'false'),
  ts TIMESTAMP(9) NOT NULL,
  TIME INDEX (ts),
);

For more details, refer to the official upgrade documentation.

Future Outlook

According to the January release of the "GreptimeDB 2025 Roadmap," GreptimeDB will continue advancing a series of key feature updates and optimizations. The next version, v0.13, will focus on refining Log and Flow Engine functionalities while introducing a more cost-effective full-text indexing implementation.

Additionally, we expect to release v1.0 (General Availability, GA version) in June, marking a major milestone for GreptimeDB. This version will encompass fundamental database capabilities, performance optimizations, Log Engine, Metric Engine, and other significant improvements.

---

About Greptime

Greptime offers industry-leading time series database products and solutions to empower IoT and Observability scenarios, enabling enterprises to uncover valuable insights from their data with less time, complexity, and cost.

GreptimeDB is an open-source, high-performance time-series database offering unified storage and analysis for metrics, logs, and events. Try it out instantly with GreptimeCloud, a fully-managed DBaaS solution—no deployment needed!

The Edge-Cloud Integrated Solution combines multimodal edge databases with cloud-based GreptimeDB to optimize IoT edge scenarios, cutting costs while boosting data performance.

Star us on GitHub or join GreptimeDB Community on Slack to get connected.