[mrj]

    I get shot down with "we use KDB here"

Well, so fundamentally a decision has been made already. You got shot down. Unless there's some significant new data that might change that decision, it is what it is. The next step is for you to decide if you can get on board with that, or if it's time to start planning your next move. I don't know anything about KDB and you might be right. But it sounds like the powers that be don't want to make this change.

Sorry, but it makes no sense to swim against the tide in an organization where you don't have the rank to make the decisions.

     I keep on advocating for some Parquet style data-store...

The worst thing you can do is to continue spending your time advocating for change, they've heard you. If you stay on and the current tech does become untenable, you are unlikely to be the hero even in that case. They might just remember you as the detractor.

[sonthonax]

> Unless there's some significant new data that might change that decision, it is what it is.

This is what I’m grasping at.

Are the challenges of writing a KDB system for back testing derivatives data which needs to work in tandem with a rust pricing library substantially different from a KDB engineered for back testing spot data.

One has complex and specific math and one doesn’t.

[michaelg7x]

I'm not sure if anyone's yet suggested that you embed your code as a library for KDB, that it could load dynamically? There's some pointer walking fun involved which Rust may _hate_ but it's not that hard and after that you'd be left with a the numerical arrays you're interested in.

[mrj]

It sounds like you're not given the tools to do your job