[deathflute]

Well, all you need to do is to look at KDB+ from kx.

All the other products that you mention are for children ;)

[jnordwick]

I know the Kx people pretty well, and they are trying to get the word out (have been for years), but it never ceases to amaze how little respect they get in the free software world. They are the leading timeseries database, and yet they don't even get a footnote in the article :(

[jmoiron]

I have actually heard of Kx and Kdb+ and Q and have looked into those products. You're right that I should have mentioned them, because they are important in that space, and in many ways they are miles ahead. The state of time series query languages is quite poor (outside of Influx's effort), so there is a lot to learn from Kdb+ as well.

I was however focusing on recent Open Source efforts and on the general approaches. Hence, I didn't really discuss in detail my own tsdb.

I also find virtually everything to do with K and Kdb to be be simultaneously impressive and utterly unfathomable:

http://code.kx.com/wsvn/code/kx/kdb%2B/s.k

This is a cheap jab to make, but it makes these systems pretty impenetrable from a source level.

[jimmcslim]

Possibly because they cost an arm and a leg (or at least that's the perception) and are therefore out of reach of most firms, apart from large utilities and hedge funds, and the language looks like line noise.

Yes, I know there is a free version, but limited to 32-bit only (and probably non-commercial?).

EDIT: 32-bit version can be used commercially.

[deathflute]

Agree about the cost. However, I would think that a wider adoption would eventually bring the cost down and perhaps even spawn a bunch of related open-source projects.

As far as readability is concerned, q(KDB+) is far more readable than k(KDB). Also, nobody stops you from adopting a coding style that is more readable. That is what I personally do.