@Biel.ai Tell me about GreptimeDB.

Hello! We’re currently using Netdata’s Prometheus remote write exporter to send metrics over to GreptimeDB. The data volume increases pretty quickly, leading us to have thousands of tables. In InfluxDB, we can manage downsampling with continuous queries at the database level. However, in GreptimeDB, it seems like flows only work for a single table. Creating and maintaining flows for so many tables is extremely challenging, especially as new tables keep getting created. Is there a way to set up a database-scoped flow (like

FROM source_database.*

) that would automatically downsample all tables in a database? If not, is this feature planned or on the roadmap?

hi all, how do you declaratively manage GreptimeDB? as best practices, i suppose we shouldn't run ad-hoc DDL queries against prod GreptimeDB? whats the recommended workflow to do

CREATE OR REPLACE FLOW

, CREATE or ALTER DATABASE etc.?

I have the following table:

CREATE TABLE IF NOT EXISTS "uptime" (
  "nvr_id" STRING NULL INVERTED INDEX,
  "value" BIGINT NULL,
  "greptime_timestamp" TIMESTAMP(9) NOT NULL,
  TIME INDEX ("greptime_timestamp"),
  PRIMARY KEY ("nvr_id")
)

And I want to run this query:

SELECT DISTINCT nvr_id FROM lrm_nvr.uptime;

This query takes ~16s to run (~99,194,924 rows). Is there a way to make this query faster? Or is there another query I can make?

What is the best SQL expression to use to retrieve all the rows from the latest scrape (i.e. the rows that have the most recent timestamp)? I tried the obvious

SELECT * FROM observation WHERE greptime_timestamp = (SELECT greptime_timestamp FROM observation ORDER BY greptime_timestamp DESC LIMIT 1);

but it appears to be doing a full table scan and takes many seconds. I'll attach an

explain analyze verbose

in a thread.

Anyone around who can help me finish figuring out the memory issues I've been posting about on this discussion? github.com/orgs/GreptimeTeam/discussions/8026 I'm jerrac over there. Specifically tell me which logs to look at so we can confirm the last_non_null merge default diagnosis and that I can try running the command to switch to the flat file mode for the sst files. I'm in PDT, and it seems like the maintainers are in a timezone different enough that they end up replying after my day is over... And I end up posting before their day has started... I'm not complaining about that, I just have a different project that really needs greptime to be running properly. So if anyone can chime in, I'd really appreciate it.

I successfully migrated a 123GB InfluxDB 2 table into a 25GB GreptimeDB table 🎉 It also requires 6x less steady-state memory. I'm impressed! I'll share more thoughts in a thread.

Great to hear that @Quentin Smith, welcome to #C03UAPCGH41

hi all, can you advise if running GreptimeDB using local WAL in prod is a common practice? Local WAL | GreptimeDB Documentation Kafka is so outdated and we dont use it in our clusters. introducing Kafka also means a whole bunch of components to monitor and maintain, and many points of failures. i'd like to hear your experience running GreptimeDB in prod using only local WAL? is switching between local WAL and noop WAL seemingless? if i want to take a node down for node maintenance, what are the steps i should take to ensure no service disruptions? e.g. switching to noop WAL, then take the node down?

Hello, We are looking in to setting up backups for our greptime installation. WHat is the status of the v2 import/export functionality? Is it ready for production use?

is row-level security on the roadmap of Greptime? this will enable fine-grained access control to data. or there is some kinda of proxy in front of GreptimeDB, which will allow us to incorporate our existing authorization infra. but that proxy will need to parse the query so it understands "who access to what"

Hi

I am trying to run project on Standalone but 127.0.0.1/dashboard not showing any thing. Help me to get UI...

image.png

Hi, I am currently working on a PoC using greptime to replace our current telemetry storage for our CI systems. I have the OSS version deployed as a cluster on K8s and I am trying to find better guidance on scaling and the ability to support our use case. We are looking to start out small and grow but I am struggling to get the best patterns of usage. 1 full CI run of our platform is about 1.5 billion log lines totaling about 50Gb of raw text. There is another 10Gb of traces and 3Gb of metrics all collected from 960+ VMs, all via the Otel Collector. I started with the base deployment using 4c and 8gb of ram across 3 pods of frontend, datanode, and meta server and a single run caused both the most used datanode to OOMKill as well as multiple of the frontend pods. Currently with it at 8c/16Gi they stay up but ram usage comes up to 13-14Gi on a few datanodes after 2 full Ci runs. I am currently for the PoC trying to figure out scaling and the optimum patterns of table creation and usage to support stages of our Ci Platform where we would have to support 25 and then 50 full runs per day, and where we are at times running multiple of these full runs concurrently. Any tips or suggestions would be appreciated.

How can I add partitions to the auto generated physical table for metrics and traces coming in from OTEL (and the logical tables if needed)? I am shipping in my PoC 5% or our total data so far and I have 1 datanode using 29Gi out of 32Gi on the pod limit. I ran into the same issue to the point that I crashed the datanode going OOM due to log volume and broke it down across 16 partitions. I would like to do the same to protect the datanodes but can't figure out how. When I did an alter table and added partitions on the

greptime_physical_table

all querying of data from the logical tables returned errors about invalid regions.

https://crates.io/crates/fastalp 分享一下我写的无损时序数据压缩算法，全球最快最好的无损时序压缩算法

60fbf718ea874952.jpg

Yo, I'm seeing a constant ~linear increase in ram usage of my greptimedb instance

image.png

In just a couple of days, same log ingestion, same services, no change in anything at all

don't really know what it could be, is this common? any insights?

I am looking for Collaborators I’m an IT engineer specializing in full-stack development and AI model development, and I’m currently looking to connect with talented people in the US, Canada, and UK for potential collaboration. If you’re interested in building innovative projects, exploring new ideas, or creating something together, I’d love to hear from you. 📩 Interested? Feel free to DM me. I’ll share the collaboration concept and further details privately.

Hi Team, We are using GreptimeDB for the first time to store Prometheus metrics via remote write, and would appreciate guidance on table design and performance tuning. Our environment GreptimeDB v1.2.1 on Kubernetes v1.36.5 3 frontends, 3 datanodes, and 1 metasrv Each datanode: 32-core CPU quota, 96 GiB memory limit, and a 2,000 GiB local SSD-backed PVC XFS on LVM for the data filesystem Automatically created table and data distribution We let GreptimeDB create the physical metric table automatically when data arrived. Below is the relevant DDL, with additional label columns and their primary-key entries omitted for brevity:

CREATE TABLE IF NOT EXISTS "greptime_physical_table" (
  "greptime_timestamp" TIMESTAMP(3) NOT NULL,
  "greptime_value" DOUBLE NULL,
  "address" STRING NULL,
  "hostname" STRING NULL,
  "instance" STRING NULL,
  "job" STRING NULL,
  -- Additional label columns omitted
  TIME INDEX ("greptime_timestamp"),
  PRIMARY KEY (
    "address", "hostname", "instance", "job"
    -- Additional label columns omitted
  )
)
ENGINE=metric
WITH (
  'comment' = 'Created on insertion',
  physical_metric_table = 'true'
);

There is no explicit partition clause or TTL in the generated table DDL. Although we have three datanodes, this table has only one data region, located on datanode-0: TypeRegion IDPlacementData region19774029430784datanode-0Internal metric metadata region19774046208000datanode-0COUNT(*) performance We tested:

SELECT COUNT(*) FROM prometheus.greptime_physical_table;

It returned approximately 18.2 million rows in more than 16 seconds. With ingestion continuing, a subsequent EXPLAIN ANALYZE showed:

MergeScanExec:
  peers=[19774029430784(4604, 0)]
  output_rows: 1
  finish_time: 17.8s
  ready_time: 8.1ms

AggregateExec: mode=Final
  elapsed_compute: 50us

AggregateExec: mode=Partial
  output_rows: 32
  elapsed_compute: 3.9ms

SeqScan:
  partition_count: {
    count: 1,
    mem_ranges: 12,
    files: 10,
    file_ranges: 10
  }
  output_rows: 24464122
  output_bytes: 186.6MiB
  elapsed_poll: 17.6s
  scan_cost: 17.8s

The aggregation is inexpensive; most time is spent scanning on the datanode. For additional context, a later region-statistics snapshot showed 28,485,421 rows, 4 SST files, approximately 48.2 MiB of SST data, and 411.5 MiB of memtable data. These snapshots were taken at different times while ingestion continued. Our questions 1. Is this exact-count performance expected for a metric-engine table? Does it require scanning and merging rows rather than using SST metadata? 2. For our three-datanode cluster, should we pre-create a partitioned physical table instead of relying on automatic creation? What initial DDL and partitioning strategy would you recommend? 3. How can a first-time user choose a reasonable partition design before collecting detailed workload statistics? Can the table be repartitioned or its regions split later? 4. Based on this example, what should we optimize first to improve query performance and make better use of the available CPU, memory, SSDs, and multiple datanodes? We understand that full-table COUNT(*) is not representative of every Prometheus query; we are using this example to understand the execution model and how to design the tables correctly from the start.

Hi team, we would appreciate guidance on the cost of a narrowly filtered information_schema.partitions query. Operational context We ingest Prometheus metrics using remote_write into metric-engine logical tables backed by a shared physical table. During investigation of uneven data distribution and an SST compaction backlog, we repartitioned prometheus_risingwave.greptime_physical_table online from one data region to 15 namespace ranges. We then needed to list partition boundaries and greptime_partition_id, and correlate those IDs with region_peers and ssts_manifest to understand placement and per-region SST distribution. This is an administrative metadata lookup, not a scan of raw metric samples and not an attempt to obtain row counts from the partitions dictionary. The query targets exactly one schema/table and returns only 15 rows:

SELECT *
FROM information_schema.partitions
WHERE table_schema = 'prometheus_risingwave'
  AND table_name = 'greptime_physical_table'
ORDER BY partition_ordinal_position;

For profiling we prepend EXPLAIN ANALYZE VERBOSE to this exact SQL. Observed timeline (different measurements, not a controlled benchmark) • Original user-observed latency: over 14 seconds. Historical plan: RepartitionExec.fetch_time=13.4s, sort compute 12us, filter compute 154us, 15 output rows. • 2026-10-03 12:32 UTC historical re-test: the same EXPLAIN query reported fetch_time=7.67s and 15 rows. • Fresh collection 2026-10-05 08:37 UTC, via Grafana datasource HTTP proxy: original SELECT returned 15 rows in 4.739s client wall time. • A separate EXPLAIN execution immediately afterward took 2.566s client wall time, with 2.45s fetch_time, SortExec 11us and FilterExec 71us. Full current plan attached in latest-plan.txt. Client wall time includes Grafana/proxy/network overhead; fetch_time is an execution-plan metric. They must not be equated. These were sequential single executions without cache reset, while normal ingestion continued; background activity was not controlled. We are NOT claiming a constant 14-second latency or a measured p95. The latest plan still shows:

FilterExec: table_schema = prometheus_risingwave AND table_name = greptime_physical_table
  RepartitionExec: ... fetch_time: 2.45s
    StreamScanAdapter

Filter output is 15 rows; the plan reports 847.7KiB output_bytes at FilterExec/RepartitionExec. We do not interpret that byte counter as exact catalog input volume or infer a root cause from it alone. Environment • Current SELECT version() reverified: 1.3.0-beta.1. • Previously verified binary commit: 133296f298c504b920772292c22f169cd46c54c9 (not freshly read from every Pod in this collection). • Latest partition readback: 15 RANGE partitions on namespace, p0–p14, region IDs 4823248273408–4823248273422. • Fresh table inventory in the two metric schemas: prometheus has 78 metric-engine tables, 13 mito tables and 3 entries with blank engine; prometheus_risingwave has 1707 metric-engine tables. Metric counts include physical tables, not only logical tables. This is not an all-catalog table count. The table-count query itself took 13.116s client wall time, a separate observation without a plan. • Last Kubernetes inventory (2026-10-03, NOT refreshed today): 3 frontend (2 CPU/8Gi each), 3 metasrv (2 CPU/4Gi), 8 datanode (8 CPU/16Gi), 3 flownode (4 CPU/8Gi); requests=limits. Four Kubernetes hosts, shared S3-compatible storage, local WAL/cache. Question Why does a metadata query filtered to a single table and returning only 15 partition rows still take more than 2 seconds in GreptimeDB? We would expect this basic single-table metadata lookup to be much faster. Could you help explain the observed latency?

What does

DROP TABLE

do when called on a logical table? Does it just remove the logical table pointer or does it also delete all the matching rows from the corresponding physical table?

Hi team, we'd like to temporarily read JSON-formatted files (totaling over 10 TB) from object storage, then count occurrences grouped by

appId

. We're planning to use an external table for this. Do you have any good solutions or suggestions? Thanks in advance. docs.greptime.com/reference/sql/create#… Json content

{
  "_index": "xlog-sd-2026-07",
  "_type": "_doc",
  "_id": "ZYDmuJ8B1n1_pofbyNyl",
  "_score": 1,
  "_source": {
    "@timestamp": "2026-07-31T15:59:20.089Z",
    "kafkaTopic": "it-business-log-filebeat",
    "appId": "58311ae4a190491ca564bc3d",
    "xlog": {
      "level": "DEBUG",
      "branchType": "",
      "zipkinParentId": "e5252737946dafa6",
      "message": "表达式：priceListType ns '',参数：{\"prodModelPrefix\":\"0#NotMatchRuleField\",\"functionDescVal\":\"0#NotMatchRuleField\",\"itemCode\":\"SU-070101-00007\",\"mainSaleModelVal\":\"0#NotMatchRuleField\",\"marketProdModelVal\":\"0#ST33-M\",\"priority\":\"7\",\"matchRuleField\":\"MARKET_PROD_MODEL\",\"prodModel\":\"ST33-M\",\"eori\":\"I\",\"priceListType\":4,\"itemCodeVal\":\"0#NotMatchRuleField\",\"prodModelVal\":\"0#NotMatchRuleField\",\"dealerType\":\"\",\"saleModelVal\":\"0#NotMatchRuleField\",\"currency\":\"CNY\",\"priceListIds\":\"06957fb9213544728bfeada94b47c8b2,143be18efdd640c2913f47f0946f95c9,9e3c4a81a52c4c149511a34f46e8d8c8,beb97f2712124517b829501fbc031cab,c32d214bde82493b886414ed4e2a2b43,e54b464191a34bdf8aec21ac8e8ae136\"},执行结果：true",
      "id": "6f7312e31d5647ae96ab678c539556ed",
      "auditLog": null,
      "optUser": "营销客服",
      "zipkinTraceId": "e5252737946dafa6",
      "ccloudTransactionId": "2901a901905c763f",
      "domain": null,
      "optTime": "2026-07-31T23:59:11.570",
      "branchId": null,
      "zipkinSpanId": "e5252737946dafa6",
      "billIds": [
        ""
      ],
      "txId": "",
      "esIndex": "xlog-sd-2026-07",
      "typeName": "业务日志",
      "application": "cwp",
      "ccloudTraceId": "795623963275fe6b20e560bec1edc30e",
      "type": "BUSINESS",
      "apiLog": null,
      "env": "PROD",
      "prodLine": "SD",
      "stackTrace": null
    },
    "podName": "app-58311ae4a190491ca564bc3d-15-7d95cb5b86-p2rsf",
    "@version": "1"
  }
}

Using GreptimeDB? Share your story with the community! We’d love to hear about your use case—whether it’s a production deployment, a personal project, or an experiment. Tell us what you’re building, why you chose GreptimeDB, and what you’ve learned along the way. Architecture details, performance results, lessons learned, and challenges are all welcome. Share your story in this thread or here: github.com/orgs/GreptimeTeam/discussions/7783

Hi Team, We are deploying GreptimeDB in cluster mode on AWS EKS using the official images (

greptime/greptimedb:v1.2.1

and

greptime/greptimedb-operator:v0.6.1

). Our registry vulnerability scanners caught several

CRITICAL

and

HIGH

CVEs. The current release images surface several critical findings entirely located within base OS packages (

curl

,

libcurl4

,

perl

,

openssl

). Are any of these specific base OS utilities (

curl

or

perl

) actively executed or relied upon at runtime by the database or operator binaries? Do you have plans to publish hardened release tags alongside your standard releases to eliminate base OS vulnerabilities automatically?

Hello community, we will be at this year's KubeCon North America in Salt Lake City, from Nov. 10 to 12. Our booth is at 262, @dennis zhuang @Lei and I will be at the event. Feel free to ping us if you are coming to the event too and want an in-person meet with our team. events.linuxfoundation.org/kubecon-cloudnativecon-north-america