Good idea.
But please note that timescaleDB is - optional (plain postgresql with the proper indices usually does the job just as well) - actually timescaledb is just a few extensions on top of plain postgresql.
So, I don't really see a lock-in here.
But a notice would be great. Maybe as part of any PR which includes more timescaledb support...
My 2 cents of experience with working with timescaledb.
PS: back then at CERT.at we used timescaledb initially for https://github.com/certtools/stats-portal already and it is just great for its purpose: to do very fast SELECT ... GROUP BY .. WHERE timestamp in INTERVAL(...) queries. That's where it shines (and coincidentally that's often what you need for data-cubes/statistics on large DBs). But you can achieve similar functionality also with plain postgresql or other databases. I see that as a functionality which may be replaced by other similar systems - if needed (and that depends only on the size of your eventDB).
On 28.11.2023, at 10:15, Bernhard Reiter bernhard@intevation.de wrote:
Signed PGP part Hello,
Am Montag 27 November 2023 12:23:56 schrieb Kamil Mankowski via IntelMQ-dev:
However, I can say what is currently available, and how I use/plan to use it:
- for final events, we use - as mentioned by Aaron - a database. We are
going to use Timescale DB,
note that the more recent features of timescale db are non-free (aka proprietary) software.
https://docs.timescale.com/about/latest/timescaledb-editions/ "Many of the most recent features of TimescaleDB are only available in TimescaleDB Community Edition."
"You cannot sell TimescaleDB Community Edition as a service"
"You can modify the TimescaleDB Community Edition source code and run it for production use."
Maybe adding a proper warning against the lock-in in the document would match IntelMQ's idea to stay open.
Regards Bernhard
-- https://intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter