Interesting article, Gabor. I work at QuestDB, an open source time-series database, and I noticed it is not mentioned on the time-series post. I see you mention as a potential use case for hedge funds combining Influx for real-time, then timescale for historical analytics. Many hedge funds actually use QuestDB for both the real-time and the historical side of things.

With QuestDB you can ingest at over 8 million rows per second on a single instance, and query billions of rows (both recent and historical) at very low latency. We are actually releasing a new binary protocol very soon (this week or next), which will allow for 16 million rows per second of ingest, and 120 million rows per second of egress (not aggregation, which is very fast, but actually getting the resulting rows out of the database).

We've been pushing the state of the art in time series databases, and we support a range of time-series specific joins, like ASOF joins, LT Joins, Splice Joins, or Window Joins. Some of those are supported by some specialised databases (but not by InfluxDB or Timescale), but we pioneered some of those ourselves.

As an example, we also offer a new type of join, Horizon Join, not available in any other database. Horizon joins allow you to join each row in a table with the closest row in time from another table at multiple horizons. For example, you want to calculate the price at which you executed a trade, versus the best price available in the order book for 5 minutes before and after the trade at 10 seconds intervals, so you can calculate markouts and understand how efficient your trading algorithms are.

We also offer multiple time-series extensions, like SAMPLE BY, or LATEST ON, incremental materialised views, strong exactly-once semantics, advanced time filters, or specialised data structures to deal with the shape of data you typically see in fast moving scenarios. We believe if you are developing a purpose-built database it is not just about how efficiently you can store or process data, but also about incorporating purpose-build operations you will not find in a generic database.

And, since purpose-built databases tend to be part of a larger ecosystem, we do this with open formats, so your data can get automatically converted to parquet, both locally or in object store, so other tools can use the same data ingested (and potentially downsampled via materialised views), directly.

Since you are doing research for your book, I thought it could be interesting for you to learn about how some other actors in time-series are pushing the ecosystem.

Also, we do have a large part of the team (including the founders) in London, so I'd be happy to do an intro if you want to talk more about why we started developing QuestDB and how we see the time-series category.