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.?

Hi Kevin, GreptimeDB does not support declarative DDL per se, but since it supports MySQL/PostgreSQL wire protocol, most modern database-as-code tools like atlas/bytebase will work perfectly for GreptimeDB.

thanks for the reply. i am aware of atlas/bytebase, but they cant do

CREATE OR REPLACE FLOW

or CREATE or ALTER DATABASE and many other things. also i am afraid there are many GreptimeDB specific syntax that are not compatible. additionally, the wire protocol for Postgres still needs more work, e.g.

information_schema.tables

only has MySQL-style metadata columns (table_collation, auto_increment, row_format…).

Taking the monitoring standalone instance in GreptimeDB enterprise cluster for example: monitoring standalone instance serves as the metrics/logs store for a running GerptimeDB enterprise edition that runs in our client’s env. It has serveral built-in tables like cluster CPU usage, logs from different components. Instead of manageing the schemas of these tables manually, GreptimeDB supports a schema-less manner: the table automatically adds a column when it ingests a row containing some column that currently does not exist. But as you mentioned, creating database/flow is not automatic, but in most cases

CREATE DATABASE/FLOW IF NOT EXIST

would be enough. If you still find it useful to manage GreptimeDB cluster in a declarative manner, I think the best approach would be add some post-installation task in the greptimedb-cluster in the helmchart. You can create a feature rqeuest in that project.

thanks for your answer, i think operationalizing tasks in heavily underrated nowadays, declarative, reproducible, automated GreptimeDB management should be the default, no manual ad-hoc commands.