Blog
Why The World Needs Flarion. Read More
Blog

Streaming in Modern Query Engines: Where DataFusion Shines

How DataFusion, Polars and DuckDB differ in streaming execution, and why incremental processing lets you query datasets larger than the memory you have.
By
Ran Reichman
•
read time
•
May 4, 2025
Heading 2

The landscape of data processing has evolved dramatically over the past few years. As datasets grow exponentially, query engines are adapting beyond traditional batch processing. Today's most innovative engines incorporate streaming capabilities to process data incrementally, enabling analysis of datasets larger than available memory while maintaining high performance. Among the leading contenders - Apache DataFusion, Polars, and DuckDB - the approaches to streaming differ significantly, with DataFusion emerging as the clear frontrunner for true streaming applications.

The Evolution of Streaming Query Execution

The term "streaming" has become somewhat ambiguous in the data processing world, spanning several distinct capabilities:

  1. Pipelined execution: Processing data in small chunks through a query plan
  2. Out-of-core processing: Handling datasets larger than available memory
  3. Continuous processing: Executing long-running queries on never-ending data streams
  4. Real-time ingestion: Continuously incorporating new data from external sources

While all three engines we're examining implement some form of streaming, they vary dramatically in their approach and capabilities. DuckDB and Polars primarily focus on the first two points—efficient execution of traditional queries—while DataFusion uniquely addresses all four aspects, providing a foundation for true streaming applications.

DataFusion's Native Streaming Architecture

Apache DataFusion, the Rust-based query engine at the heart of the Apache Arrow ecosystem, was designed with streaming as a core architectural principle. Most physical operators in DataFusion support an "Unbounded" execution mode specifically for handling infinite streams.

DataFusion's streaming architecture delivers several key advantages:

Streaming-First Design: While other engines adapted batch processing for streaming, DataFusion incorporates streaming principles natively. Its physical execution plan includes operators like StreamTableExec and SymmetricHashJoinExec specifically designed for unbounded data. This fundamental design choice enables true continuous query execution.

Streaming Join Support: Where traditional engines struggle with joins on streaming data, DataFusion's SymmetricHashJoinExec operator efficiently joins unbounded streams on the fly. This critical capability unlocks complex real-time analytics that would otherwise require batch window processing.

Arrow Integration: DataFusion processes data in Arrow record batches, providing memory-efficient, zero-copy operations on columnar data. This tight integration with Arrow gives DataFusion significant performance advantages when streaming data between systems or components.

Low-Level API Flexibility: DataFusion provides the foundational building blocks needed to construct sophisticated streaming applications. While higher-level functionality like watermarking is still emerging, its extensible architecture allows developers to implement these capabilities directly.

Polars and DuckDB: Streaming Capabilities

Both Polars and DuckDB offer capabilities related to data processing, though with important limitations for true streaming:

Polars' Streaming Status: Polars previously implemented a streaming execution mode that processed data in batches. However, it's worth noting that this streaming engine has been deprecated, and while the Polars team is working on a new streaming implementation, it's not currently something to build production systems on. Polars continues to excel at single-node workloads where memory isn't a significant constraint, offering exceptional performance for data transformation and analytics.

DuckDB Pipelined Execution: DuckDB employs a vectorized, pipelined execution model that processes data in small chunks (vectors) through query operators. This approach is particularly effective for quick in-memory operations and can handle streaming workloads efficiently when the data volumes definitively fit in memory. DuckDB's columnar architecture and parallel execution make analytical queries remarkably fast for these scenarios.

Neither engine is designed for continuous streaming of unbounded data. Both lack built-in stream ingestion capabilities and don't maintain persistent state across query executions. Each query runs to completion on the data available at execution time.

Choosing the Right Tool for Your Streaming Needs

Understanding the key differences in streaming capabilities helps select the right tool for specific use cases:

For True Streaming Applications: DataFusion stands out when you need continuous processing of unbounded data streams. Its ability to handle streaming joins, process Kafka data directly through StreamTableExec, and maintain state between batches makes it ideal for real-time applications with continuous data flows.

For Large Dataset Processing: Polars and DuckDB excel when processing large files or datasets that don't fit in memory. Their streaming execution modes efficiently handle out-of-core processing for analytics, ETL, and data transformation tasks with excellent performance.

Use Case Examples:

  • Real-time analytics pipeline: DataFusion provides the foundation for building systems that continuously ingest from Kafka and maintain up-to-date results.
  • Large log file analysis: Polars and DuckDB can efficiently process multi-gigabyte log files on modest hardware, even if the files exceed available memory.
  • Periodic batch processing: For scheduled ETL jobs that process accumulated data at intervals, Polars and DuckDB offer simpler implementation with excellent performance.

Each engine shines in its intended domain. DataFusion excels at true streaming while Polars and DuckDB deliver outstanding performance for analytical workloads and large dataset processing.

The Future of Streaming Query Engines

As data volumes continue growing and real-time analytics becomes increasingly critical, each engine is evolving to better serve its core use cases:

DataFusion continues advancing its streaming capabilities with ongoing development focused on:

  • Native watermarking support for proper event-time processing
  • Built-in state checkpointing for fault tolerance
  • Enhanced connector ecosystem for popular streaming sources

Polars and DuckDB continue to optimize their engines for analytical performance within their target domains, with Polars working on a new streaming engine and DuckDB enhancing its vectorized execution capabilities.

At Flarion, we believe in selecting the right tool for each specific task. We're always evaluating the strengths of different engines and are happy to give each one a chance in the domain where it shines. This pragmatic approach means using DataFusion when true streaming capabilities are required, while leveraging Polars for high-performance single-node analytics and DuckDB for quick in-memory operations.

‍

Resources

Related Posts

Blog
This is some text inside of a div block.
Why the World Needs Flarion

Why we built Flarion: the cost of processing large data volumes, the pressure for faster results, and the approach we took to both.

read time
-
November 27, 2024

Did you know that data-driven organizations spend up to 40% of their IT budgets on data processing alone?

As organizations scale their data processing capabilities, two critical challenges emerge: the mounting costs of processing big data and the pressing need for faster performance. Today, we're sharing our journey and explaining why Flarion is transforming how organizations leverage their data assets while staying competitive in an increasingly data-driven world.

The Journey to Better Data Processing

Through years of experience across diverse industries, Flarion’s co-founders witnessed the universal struggle of escalating data processing costs and performance bottlenecks.

During his years building data processing systems for mass-scale consumer applications and autonomous vehicles, Ran experienced firsthand how organizations struggled with the growing costs and performance demands of expanding datasets. In consumer applications, better insights can help create great experiences for hundreds of millions of people, but the high computational costs and processing limitations often make this prohibitively expensive. In autonomous vehicles, data processing at scale allows us to understand and tackle the toughest "long tail" challenges, but technical limitations can make this slow and cost-inefficient.

Through his extensive work with enterprises across various industries, Udi observed a consistent pattern: organizations were hitting both a performance and cost ceiling in their data processing capabilities. Despite significant investments in infrastructure and talent, companies found themselves constrained by processing limitations that held back their ability to launch new features or products while managing escalating infrastructure costs.

The Evolution of Data Processing Needs

The landscape of data processing has evolved dramatically. What started as simple analytics has transformed into complex data pipelines processing hundreds of terabytes daily. These diverse challenges underline the pressing need for solutions that address both speed and cost at scale.

In automotive, processing speed directly impacts vehicle safety and performance, while processing costs affect vehicle affordability and market competitiveness. In financial services, faster data processing enables real-time decision-making and better risk assessment, but the infrastructure costs of high-frequency trading and real-time analytics can quickly erode profit margins. For e-commerce companies, efficient data processing means better customer recommendations and inventory management, yet the cost of processing massive customer datasets across global markets can be prohibitive. Almost every industry relies heavily on efficient data processing and analytics, making both speed and cost optimization critical factors in maintaining competitive advantage.

A New Approach to Performance

Traditional approaches to improving data processing often involve extensive code changes, specialized expertise, or specific deployment requirements. For enterprises with massive legacy codebases, these solutions are often impractical or impossible to implement, creating additional complexity without solving the fundamental challenges of performance and cost efficiency.

We built Flarion with a different vision: what if organizations could dramatically improve their data processing performance without changing their code or disrupting existing workflows? With new Spark, Hadoop and Ray execution engines, we've created a solution that delivers up to 3x performance improvement while maintaining robust reliability and full compatibility. Most importantly, Flarion can be implemented in just 5 minutes, requiring minimal effort from organizations looking to modernize their data stack.

Enabling Innovation Through Efficiency

The impact of accelerated data processing extends far beyond just faster completion times. When organizations can process their data more efficiently and cost-effectively, they can explore new use cases, launch innovative features, and focus on extracting value from their data rather than managing infrastructure costs.

For AI and machine learning applications, efficient data processing is becoming increasingly crucial. The ability to process large datasets quickly and reliably can mean the difference between a successful model deployment and a missed opportunity. With Flarion, organizations can focus on innovation rather than infrastructure optimization, all while maintaining their existing codebase and operations.

The Future of Data Processing

As we enter an era where data drives competitive advantage, organizations need solutions that enable them to process more data, faster and more cost-effectively. The future of data processing isn't just about handling today's workloads - it's about being ready for tomorrow's challenges while managing costs sustainably.

With Flarion, organizations are not just keeping pace—they’re leading the charge into a data-driven future. Our solution enables organizations to unlock the full potential of their data assets, whether they're running data processing in the cloud or on-premises. By delivering significant performance improvements through advanced optimization techniques, we're helping organizations process their data more efficiently while reducing their infrastructure costs. Most importantly, we're doing this in a way that respects the reality of enterprise systems - with a solution that can be implemented in minutes, not months.

The future of data processing should empower organizations to focus on innovation and value creation without being held back by legacy infrastructure or rising costs.

At Flarion, we're making that future a reality.

Featured Blog
Blog
The Data Processing Honey Badger: Why Spark Persists

read time
-
September 10, 2026

Development on Apache Spark started at Berkeley in 2009, and the first production release shipped on May 30, 2014. In the twelve years since, it has become the analytics workhorse for most of the large corporations in the world, across industries and scale, from seed-stage startups to Fortune 10 enterprises. Every year or so someone declares it old, past its peak, saddled with the JVM, and generally "legacy." And every year there is more of it. What accounts for the disconnect? In this post we'll walk through what we see across customer deployments and why we expect that in ten years there will still be a whole lot of Spark, and probably much more than there is today.

Infinite Scale

Spark scales very well. It’s not rare to see customers running workloads reading dozens of TB, while at the same time other customers process a few GB per workload. The result: for data engineering teams who don’t know how much data they’ll need to process, it’s a clean and easy decision to adopt Spark.

Network Effects

While it’s quite easy to use Spark, especially with PySpark, it’s not easy to deploy it and maintain it. But once the data platform adopts the tooling and learns how to maintain Spark, it is rarely motivated to migrate a piece of critical infrastructure to an unproven alternative, and instead are motivated to push more people to use Spark.

The Challenge of Migrating

Large companies can have thousands of jobs running at any given time, spread across the entire organization. The idea of pushing the various teams to migrate to a new platform is usually a complete non-starter. Oftentimes even gradually moving to systems like Ray is unwelcome due to the cost of maintaining multipledata platforms.

A First Class Citizen in the Data Lake

Delta Lake, Iceberg, and Hudi were each born with Spark as the reference implementation. The result is that Spark works well out-of-the-box with all three, while other systems are gradually adding support. Engineering teams want the best and most recent lakehouse technology and generally Spark supports it. .

Extensibility

Spark is easy to extend without forking. Catalyst exposes optimizer rules, planning strategies, and catalog plugins. DataSource V2 lets anyone teach Spark to read a new system. User defined functions (UDFs) let teams introduce Python or Scala logic into the middle of a pipeline without leaving the framework. Plug-ins allow the introduction of new libraries into the system. The result is that the thing people would otherwise leave Spark to get, a new connector, a custom optimization, a domain-specific function library, usually shows up inside Spark instead.

The Competition

Flink is used for some streaming use cases, Ray for AI use cases, Trino for interactive SQL, DuckDB and Polars for data that fits on one machine. Data warehouses with proprietary engines are taking some share. But at this point nobody is really trying to invent a new full-fledged system to replace Spark. The competition is either specializing in a lane or building underneath it.

Improved Engines

In Spark, the underlying engine is not static. The API hasn’t changed much since DataFrames arrived, but adding Tungsten improved performance with whole stage code generation that’s close to the hardware, while query optimizations, fast paths, and new operators also make the same workload faster without code changes. Databricks added Photon, we produced Flarion, and open source brought Gluten and Comet. It’s possible to stay on Spark and get modern performance, similar to how PostgreSQL keeps getting better and adding functionality without the API changing.

Summing Up

The Spark API is likely going to be with us for a long time, but under the hood a lot is going to change. Piece by piece the engine is being replaced, and it's plausible that in ten years none of the original execution code will be left, while every job still runs and every DataFrame still looks the same. It's the Ship of Theseus, except in this version the ship gets faster with every plank. 

‍

Featured Blog
Blog
The Hard Part of Upgrading Spark Versions Isn’t the Code

AI agents can now rewrite Spark jobs for upgrades. Slack, Uber, and Facebook's migrations show the real work: proving the output data didn't change.

read time
-
August 18, 2026

A few weeks ago AWS shipped the Spark Upgrade Agent, an AI agent that migrates Spark jobs to Spark 4.0. You point it at a repo, it rewrites deprecated APIs, adjusts for behavioral changes, updates the build for Scala 2.13, submits the result to an EMR cluster, and iterates on failures until the job runs. It handles both Scala and PySpark, and it works the way you'd hope an agent would: plan, transform, validate, repeat. The potential payoff is large - newer Spark versions have better performance and years of accumulated bug fixes.

It looks like a good tool and data teams looking into a Spark migration should consider it, but what we’ve found is that in the enterprise, rewriting code isn’t the main impediment to upgrading Spark workloads. Spark programs are part of complex pipelines, parts of which are poorly understood or maintained, and making changes to a sensitive system is inherently risky. There’s no guarantee that the output data will actually remain the same, and data integrity is the fundamental challenge of completing such a migration.

Several companies have written in detail about major Spark upgrades, and the data integrity challenge is a recurring theme.

Slack

Slack's migration from Spark 2 to Spark 3 took about a year across 60+ EMR clusters and 40+ teams. They saw some code-level breakage: `RAND()` in join keys became an `AnalysisException`, some casts that Spark 2 tolerated started failing, the `Greatest` function handled NULLs differently than its Hive counterpart. Validation was a much larger effort. For billing pipelines, Slack required exact matches, building test tables from production data on Spark 3 and running `EXCEPT` and `COUNT` comparisons in Trino against the Spark 2 outputs, with a Python framework for digging into every discrepancy. The discrepancies weren't all bugs. Non-deterministic row ordering, timestamp variations, and genuine semantic differences between Hive and Spark implementations all produce diffs that need to be investigated. Some are noise, some are real regressions.

Uber

Uber's version of this is bigger and more instructive. They migrated from Spark 2.4 to 3.3 with over two million Spark applications running daily. The code transformation was automated with Polyglot Piranha, their structural rewrite tool. It parses the source code into an AST, matches patterns, and applies transformation rules, including inserting legacy flags like `spark.sql.legacy.allowUntypedScalaUDF` where old behavior had to be preserved. This scaled well. The problem that shaped the whole project was stated plainly: "We had over 40,000 Spark apps, so we couldn't decentralize the data validation." No staging environment, no test cases, no way to ask every team to eyeball their own outputs.

So the flagship engineering artifact of Uber's Spark upgrade wasn't actually a code migrator but Iron Dome: a shadow-testing framework which runs the migrated job against production inputs, rewrites output paths at runtime so results land in staging instead of production, puts guardrails at the Hadoop FileSystem interface so a misrouted write can't touch real data, then compares the shadow output against the production run and only marks the job migrated when they agree. 

Facebook

None of this is specific to the Spark 2-to-3 transition, or even to Spark versions. When Facebook moved Hive workloads onto Spark SQL back in 2017, they ran shadow pipelines writing to tables suffixed `_spark_shadow` so downstream jobs were never exposed, used count checks as a cheap first filter, and reached for full hash validation of outputs only reluctantly (because, as they put it, the hash validation was "sometimes even heavier than the query itself.") Funny enough, proving the new engine produced the same answer could cost more compute than producing the answer. They note that non-deterministic UDFs made validation hard, the same diff-adjudication problem Slack hit eight years later.

Takeaway

In the enterprise, migrations are rightfully considered risky projects that take time and incur risk. This is especially true in the age of AI given that the things that AI doesn’t necessarily deliver are also the riskiest parts of the migration - edge cases, data integrity, the long tail, etc. This isn’t to say that AI can’t help with building tooling for a migration, it clearly can, but usually an agent isn’t going to do the trick alone.

At Flarion, a major goal of ours is to give users the best possible performance and access to modern features without requiring a code migration. If you can get the benefits of Spark 4.2 while staying on Spark 3.4 then that’s a huge time save and reduction in risk. Of course, the data integrity problem doesn’t disappear, it’s now Flarion’s responsibility. One we’re happy to shoulder.

‍

Oops! Something went wrong while submitting the form.