Disclosure: I'm Director of Engineering at Draft.dev, which produces technical content for Haevek. I'm publishing this because the technical story is genuinely interesting and worth sharing.
I spent years as a data engineer and BI developer before moving into engineering leadership. Part of that time was at an iGaming company supporting millions of active customers across multiple regulated jurisdictions, where the infrastructure had to stay on-prem because the regulations in certain markets don't give you a choice about where your data lives, and where real-time fraud detection runs on every transaction. I know what it costs to keep that kind of pipeline running, and I know what performance claims usually look like when you get close enough to test them.
So when I came across Haevek, a startup claiming to have rebuilt Apache Spark from scratch and made it up to 25 times faster, I went and spoke to the founding team, Andrew Hoeft and Kevin Eveker, to find out whether the story held up.
Here's what they told me.
The problem they were solving
The founding problem surfaced twice, from different directions. The first was a government program running a 15-year-old distributed compute system written in C++. Fast enough to meet processing requirements, but so complex that it needed several dozen engineers each with PhDs and two decades of C++ experience just to keep it running. The team had looked at Apache Spark as a path to a leaner architecture. It wasn't fast enough. The second was a separate program where dev environments alone were running $100,000 to $200,000 a month in compute before anything reached production. The customer's position was plain: you can't keep throwing infrastructure at this problem.
Both situations are immediately recognizable if you've worked in data engineering at any real scale. The conversation is rarely whether you can process something. It's whether you can process it without the infrastructure bill becoming the headline.
Why they chose Rust
The obvious implementation language was C++. The team decided against it for a reason anyone who has maintained large C++ codebases will recognize: C++ puts the entire burden of memory safety on the developer. Kevin had spent years in the commercial world fixing other engineers' C++ code, tracing memory leaks with tooling that frequently couldn't catch them, rewriting implementations that worked on paper but couldn't be sustained in production. Building a new compute foundation in C++ would mean carrying that cost forward indefinitely.
They spent a winter holiday benchmarking several major backend systems language: C++, C, Go, Python, Rust, and Java. Rust matched or exceeded C++-level performance across every test that mattered, enforced memory safety at compile time through strict ownership and borrowing rules, and produced no GC pauses in production workloads. For anyone who has watched a Spark job stall because the JVM decided it was time to collect garbage, that last point lands immediately.
In June 2025, NSA and CISA published joint guidance recommending memory-safe languages as a primary strategy for reducing software vulnerabilities. Google Project Zero research cited in the guidance found 75% of CVEs exploited in the real world are memory safety vulnerabilities. Android reduced its share from 76% to 24% by switching new development to Rust. For Haevek's government and defense customers, the language choice is both a performance decision and a compliance requirement their own agencies are driving.
What actually failed (twice)
The team went through three complete rewrites of the core engine. Andrew's explanation of why is the most technically interesting part of the story.
High-performance compiled languages require static typing. You define at compile time how the whole system is going to work, and that's where the performance comes from. A general-purpose distributed compute engine has to handle any workload, with different data types, different pipeline shapes, different compute profiles, and different source and destination formats. Those two requirements pull directly against each other, and working out how to satisfy both simultaneously while keeping the system usable for developers building jobs on top of it took three attempts. The techniques developed in the process are now the foundation of the patent portfolio.
Having worked on data pipelines where the architecture tradeoffs between flexibility and performance were a constant negotiation, I understand why this is hard. The moment you try to make something both fast and general, you are fighting against what compiled systems naturally reward.
The results
A dozen person-years of engineering later, Falcon processes distributed workloads at up to 25 times the speed of Spark, deploys anywhere Kubernetes runs, and already covers approximately 70 to 80 percent of the functionality data engineering teams use day to day.
In one case, running against compiled C++ code written for a government program, they measured up to six times faster performance on certain operations. Kevin's explanation: Falcon enables developers to easily write workloads that distribute well end-to-end, even distributing reading of individual large input files". Andrew's explanation: developers writing in compiled languages tend to optimise the inner loop and treat serialisation, deserialisation, queuing, and cache management as things the language will handle. At scale, those assumptions accumulate. A customer who initially told the team the performance claims sounded too good to be true later came back and confirmed the numbers held up across their own workloads. The first customers to put Falcon into production replaced their Databricks workloads in eight days`.
The benchmark question
This is the thing I pushed on most, because inflated performance claims are common in this space. A big number on a product homepage is not the same as a number on your infrastructure, and the methodology behind vendor benchmarks is often buried where most readers never find it.
Haevek's answer is their Falcon test flight: run your actual workloads on equivalent infrastructure before any commercial commitment and see what the numbers look like on your own data. That sequence, skepticism followed by a result generated on your own infrastructure, is exactly how the evaluation should go.
Is it worth a closer look?
If you are running significant Spark or Databricks workloads and the infrastructure cost or job latency is a real problem, the test flight model keeps the evaluation cost low. You are not being asked to trust a benchmark. You are being offered a chance to generate your own data point.
The rebuild story is real, the technical reasoning is solid, and the results are specific enough to be testable. You can find out more at haevek.com.
Top comments (1)
Interesting story. This was a key technical takeaway for me -