There’s also Q [0] and kdb+ [1] as another example.
[0] https://en.m.wikipedia.org/wiki/Q_(programming_language_from...
[0] https://en.m.wikipedia.org/wiki/Q_(programming_language_from...
Wikipedia has an article on Time series databases and they contain a short list of popular TSDBs [0]. On that list 11 are libre-software to some degree and 4 are commercial. Relational TSDBs are new to the open source space but they're still being built despite there being the existing kdb+. This shows that people will spend considerably more funds to engineer a replacement (and give that replacement away for free) to avoid using a closed source product for this use case.
[0] - https://en.wikipedia.org/wiki/Time_series_database#List_of_t...
Market adoption could be better, but the license costs around $100,000/year (probably the most expensive software per kilobyte). Fintech can afford it, other industries can’t.
They have a an SQLish interface, that allows non-specialists to get work done, but anything serious needs to move beyond that.
I haven't used it in a few years, but queries had to be carefully optimized -- swapping the order in a where clause could cause order of magnitude differences in performance. Also it is append-optimized. If you need to update or insert data, it is a nontrivial exercise.
This seems pretty much next generation k.
We can see how things goes.
Single machine, because it can't handle parallel queries, at all, and there are no options to scale it.
Every financial institution I've worked at is busily unwinding their investment in q/kdb. It's legacy tech.
I even met a programmer who hacked something together in Java using the same columnar kdb layout but, you know, multithreaded, so different basket optimization jobs could run simultaneously on the same store.