When Not to Use Rust in Data Platform Internals

Rust can be high leverage for critical internals. It is not a universal first choice.

Decision question

Is the workload risk profile high enough to justify Rust ownership cost now?

Cases where Rust is usually not first

• short-lived exploratory processing
• low-throughput internal automation
• teams without systems-level maintenance capacity
• problem statements still unclear at architecture level

Better first moves in those cases

• stabilize workload boundaries and interfaces first
• improve observability before replatforming
• use higher-level tooling to validate requirements quickly
• reserve Rust adoption for paths with proven reliability/latency pain

Cases where Rust is justified

• sustained high-throughput critical workloads
• concurrency bugs causing recurring incidents
• strict latency SLOs with poor predictability under load
• long-term ownership commitment already in place

Recommendation

Adopt Rust where operational risk and throughput sensitivity are both high. Avoid broad language migrations without decision-level evidence.

KPI target example

• priority incident frequency on target service reduced by 40%
• p99 latency variance reduced by 30%
• on-call diagnosis time reduced due to fewer undefined runtime failures

If this choice is currently unclear, a direct conversation with Stratorys is designed to make it explicit.