Information about (dis)advantages of the supported protocols

[linuxtim]

Firstly - thanks to everyone for writing this software and releasing it as open source!

As a personal project, I'm considering using GreptimeDB for storing and querying data within my house - e.g. environmental data like humidity, temperature, CO₂ concentration, and also data like grid and solar PV power, voltage and current. In total something on the order of 1 to 10 data points per second. I will self-host the database on a small server (initially x86-64, but I will probably move to ARM in due course). Storage will be local.

I've used Postgres, MySQL and Prometheus both professionally and for my own personal projects, but I haven't used GreptimeDB before. For this home sensor data, I've previously been using SQLite.

For at least some of the sensor data that I will be gathering, I will create code to read the sensors, so I am free to choose how to present this data to the tsdb.

The documentation details various supported protocols (e.g. InfluxDB Line Protocol, Postgres etc.) but I couldn't find any information comparing pros and cons of each protocol, e.g.

• Which (if any) are better supported
• Performance trade-offs (CPU, bandwidth)
• Which are best matched to the underlying storage mechanisms (e.g. avoid implicit type conversions)

Any information gratefully received. Thanks! Tim.

[killme2008]

Great question! Sorry for missing the documentation on this choice.

We support multiple ingestion protocols mainly for compatibility, so users can migrate their existing stacks easily.

From a performance standpoint, gRPC is ideal for ingestion, while MySQL/PostgreSQL is preferred for queries.

For your this personal project, using MySQL or PostgreSQL for read/write operations is simpler and easier to implement.

[linuxtim]

Thanks for that. Initially I'll look at using PostgreSQL then, because the rust-postgres crate has a similar API to the Rusqlite crate which I'm already using. gRPC might actually be interesting in the future, when implementing new sensors, because one possible design would be to have the lightweight devices (microcontrollers running RTOS or bare metal) which are physically attached to the sensors report their data directly to the TSDB.