One of the main pain points I keep hearing about kdb is the complexity and its consequences in terms of time spent trying to do anything, and money spent on con

One of the main pain points I keep hearing about kdb is the complexity and its consequences in terms of time spent trying to do anything, and money spent on consultants. The language is efficient and you can write pages of Java with 2 lines of code (they keep bashing Java for some reason). But it takes very specialized talent to get there. I heard that Bitmex was paying up to 6 figures to find consultants in London and have them move to HK which illustrates the degree of key-man risk inherent with kdb. Performance is good but comes at a massive usability cost. kdb+ brag about very succinct commands and even error messages but the small gain in efficiency from one less character in the error message is at the detriment of the user trying to work with it. QuestDB (http://questdb.io http://questdb.io) is an alternative to kdb as time-series data store (disclosure, i am one of the authors). We left trading to build it and show you can get the same speed without sacrificing usability. Users get better performance than kdb+, but can use SQL, ACID transactions. It is already in production with a few exchanges and HF, and it is open-source! Hopefully, kdb users looking for a replacement find questdb helpful for their projects :-)