| I'm speaking as someone who: - has worked in finance for both hedge funds and banks - has managed a project where KDB was mandated to be used by mgmt. - on the above project, tasked one of the smartest developers I've ever worked with as the person to learn KDB and use it in the application - I'm a SRE (and former Operations) so that colors my perspective. Given the above, I list out the pros and cons: PROS - KDB is pretty fast (on some metrics of fast) CONS - VERY few people can write/read good Q (compared to say people who know Pandas/SKlearn etc) - The learning curve is INCREDIBLY steep. Even the most cited documentation and tutorials have something like this in the intro "are you really sure you need KDB? B/c Q is REALLY hard to learn" - As you mention, open source industry standards have come a LONG way since it made sense to have KDB (e.g. in the late 2000s/early 2010s) Conclusion: If you have a lot of in house expertise, then sure, it probably makes sense. If you are starting from scratch, I would not recommend it. On that note, this point stood out:
> People have built their livelihoods around it and use it as a hammer for all sorts of nails. If you work in the industry long enough, you will find a lot of complexity added to systems for three reasons: 1. Some things in finance really do need to be complex due to the math etc 2. Smart people with quant backgrounds tend to LOVE complex things. 3. Smart, rational people realize that adding complexity is one way to build a fortress around their job. This is particularly true in high paying firms where people realize that it's their knowledge of the complex systems that is keeps them in that high paying job. Give that, if you are looking to make a name for yourself at your firm: making things run faster, with fewer issues etc is a good way to stand out. Just be careful that you don't eliminate so much complexity that people get mad at you. |