Apache SeaTunnel June 2026 Roundup: Control Plane Evolution, Smarter Governance, and a Growing Connector Ecosystem

Hi, SeaTunnel Community!

The Apache SeaTunnel June 2026 monthly roundup is here. Throughout June, the project merged 125 pull requests, a significant increase from 87 PRs in May.

More importantly, June wasn't simply about fixing bugs or adding new connectors. Development across the project clearly converged around three major strategic directions:

• The control plane and engine abstractions continued to evolve. Features such as table-level fault isolation for multi-table synchronization, the introduction of the StateStore abstraction, task workload monitoring, and reporting of non-terminal job states indicate that Zeta is evolving beyond simply executing jobs toward becoming a platform that is easier to govern, recover, and observe in production.

• The Connector-V2 ecosystem continued to expand. New connectors and capabilities—including BigQuery Sink, MQTT Source, Salesforce Source, Vitess CDC, and Google Cloud Bigtable integration—further broadened SeaTunnel's coverage across modern data infrastructure.

• The data processing layer became more powerful. Features such as Schema Evolution for file connectors, the Calcite SQL Transform Plugin, and built-in Base64 SQL functions demonstrate that SeaTunnel is no longer focused solely on moving data. It is steadily evolving into a platform capable of performing increasingly sophisticated data transformation and processing.

1. Project Overview

1.1 Development Statistics

Development activity in June can be categorized into four major areas:

• New Features: 18
• Performance Improvements: 0
• Bug Fixes: 40
• Architecture Improvements: 67

Compared with May, the most notable change was the substantial increase in architecture-related pull requests.

This signals an important shift in the project's priorities. Rather than focusing solely on shipping new connectors, the community invested heavily in strengthening SeaTunnel's underlying architecture, engineering quality, documentation, stability, and system abstractions. These foundational improvements lay the groundwork for long-term scalability and maintainability.

1.2 Module Distribution

PR distribution across major modules:

Module	PRs
seatunnel-connectors-v2	35
docs	27
seatunnel-engine	22
seatunnel-connectors-v2/connector-cdc	14
seatunnel-e2e	12
seatunnel-api	3
.github/ci	2
Other	10

One particularly noteworthy trend is the significant increase in documentation-related contributions.

Throughout June, the community invested considerable effort into transforming operational knowledge into well-structured documentation. Examples include documentation covering:

• Zeta StateStore and recovery mechanisms
• CDC production deployment cookbooks
• REST API lifecycle documentation
• Operational best practices for production environments

While documentation doesn't directly improve throughput or latency, it dramatically enhances SeaTunnel's usability, maintainability, and adoption in enterprise environments. Making operational knowledge explicit lowers the learning curve for new users and enables teams to deploy SeaTunnel more confidently in production.

2. Top Contributors

Rank	GitHub User	Merged PRs	Primary Contribution Categories
1	DanielLeens	27	Features ×1 · Bug Fixes ×5 · Architecture ×21
2	zhangshenghang	26	Features ×1 · Bug Fixes ×11 · Architecture ×14
3	nzw921rx	19	Features ×2 · Bug Fixes ×6 · Architecture ×11
4	davidzollo	7	Bug Fixes ×2 · Architecture ×5
5	dybyte	4	Features ×3 · Architecture ×1
6	yzeng1618	4	Features ×1 · Bug Fixes ×1 · Architecture ×2
7	QuakeWang	4	Bug Fixes ×4
8	JeremyXin	4	Bug Fixes ×2 · Architecture ×2
9	DanielCarter-stack	4	Bug Fixes ×1 · Architecture ×3
10	yuluo-yx	2	Bug Fixes ×2
11	ricky2129	2	Features ×1 · Bug Fixes ×1
12	MyeoungDev	2	Features ×2
13	ss666	2	Features ×1 · Architecture ×1
14	CosmosNi	1	Architecture ×1
15	LeonYoah	1	Bug Fix ×1
16	Marx-Carvalho	1	Architecture ×1
17	hawk9821	1	Bug Fix ×1
18	77amyfly	1	Bug Fix ×1
19	JAEKWANG97	1	Feature ×1
20	NixonWahome	1	Feature ×1
21	GabrielBBaldez	1	Feature ×1
22	niumy0701	1	Architecture ×1
23	15037143579	1	Architecture ×1
24	CloverDew	1	Bug Fix ×1
25	xxzuo	1	Architecture ×1
26	Muktha9491	1	Feature ×1
27	programmerloverun	1	Feature ×1
28	zooo-code	1	Bug Fix ×1
29	zhiliang-wu	1	Feature ×1
30	doyong365	1	Architecture ×1
31	loupipalien	1	Architecture ×1

June also highlighted the growing diversity of the Apache SeaTunnel community.

Contributors from different organizations and regions collaborated across connector development, engine architecture, documentation, testing, and ecosystem improvements. Beyond the number of merged PRs, the sustained focus on architectural evolution demonstrates the community's commitment to building a more robust, scalable, and enterprise-ready data integration platform.

3. Key Technical Highlights

Looking across all the pull requests merged in June, the major technical work can be grouped into four strategic areas.

3.1 Multi-Table Synchronization Enters a New Stage of Reliability

One of the most significant improvements is the introduction of table-level fault isolation for multi-table synchronization. (#10600)

Previously, a failure in a single table could cause the entire synchronization job to fail. With the new fault isolation mechanism, SeaTunnel moves away from an all-or-nothing execution model toward more fine-grained failure handling.

This is an important milestone because multi-table synchronization has become one of SeaTunnel's primary production use cases. As deployments continue to scale, the ability to isolate failures at the table level becomes essential for improving reliability and reducing operational costs.

3.2 File Connectors and SQL Processing Become More Powerful

June also brought substantial improvements to SeaTunnel's data processing capabilities.

The file connector now supports Schema Evolution, enabling runtime handling of schema changes such as column additions, removals, renames, and updates. (#10744)

At the same time, the introduction of the Calcite SQL Transform Plugin provides a far more powerful SQL transformation framework with extensible UDF support. (#11062)

Built-in SQL capabilities were also expanded through new Base64 functions, demonstrating that SQL Transform is evolving beyond simple projection and filtering into a more comprehensive data processing layer. (#11114)

3.3 Zeta Continues Decoupling from Hazelcast IMap

Another major architectural milestone is the introduction of the new StateStore abstraction. (#10812)

Historically, parts of the engine relied directly on Hazelcast's IMap implementation for state management. The new abstraction layer removes this tight coupling by introducing generic state storage interfaces.

This architectural evolution opens the door for future support of alternative state backends, hybrid storage strategies, and more flexible runtime implementations.

3.4 Connector Expansion Continues with a Stronger Focus on Production Readiness

The Connector-V2 ecosystem continued to grow throughout June.

New connectors and integrations include:

• BigQuery Sink
• MQTT Source
• Salesforce Source
• Vitess CDC
• Google Cloud Bigtable Source
• Google Cloud Bigtable Sink

Alongside these additions, the community delivered numerous stability improvements across existing connectors and infrastructure, including fixes for:

• Apache Paimon
• CDC connectors
• JdbcHive integration tests
• UI NaN display issues
• End-to-End testing stability
• JDK 8 compatibility

Rather than simply increasing the number of supported systems, the project is placing greater emphasis on connector maturity, compatibility, and production readiness.

4. In-Depth Analysis of Major Technical Changes

Among all the work completed in June, five pull requests best represent the project's technical direction. Below, we examine each of them from three perspectives:

• Background
• Implementation
• Impact

4.1 PR #10600 — Table-Level Fault Isolation: From Global Failure to Granular Recovery

PR Size

23 files changed

1,648 insertions

144 deletions

Background

Multi-table synchronization has become one of Apache SeaTunnel's core production scenarios.

Previously, if a single table encountered a write failure, the entire synchronization job would often fail.

In large-scale production environments, this creates a classic "long-tail" problem:

Imagine synchronizing 100 tables. If 99 complete successfully while just one fails, the entire job must be rerun, wasting considerable time and computing resources.

As deployments continue to grow, this all-or-nothing failure model becomes increasingly expensive.

Core Design

This pull request introduces new abstractions, including:

• MultiTableCommonOptions
• MultiTableFailurePolicy

These abstractions expose failure handling as an explicit configuration rather than hiding it inside runtime logic.

Key implementation:

public class MultiTableCommonOptions {

    @Experimental
    public static final Option<MultiTableFailurePolicy> MULTI_TABLE_FAILURE_POLICY =
            Options.key("multi_table.failure_policy")
                    .enumType(MultiTableFailurePolicy.class)

How It Works

Instead of treating every failure as a job-ending event, the runtime can now make decisions based on configurable policies.

Possible behaviors include:

• Recording failed tables
• Continuing synchronization for healthy tables
• Preserving failure context for later recovery

This transforms failure handling from a single execution path into policy-driven runtime behavior.

Impact

Connector Layer

Multi-table sink implementations can now understand failure policies and receive table-level failure metadata.

Engine Layer

The coordinator propagates failure context throughout the job lifecycle, enabling more intelligent recovery behavior.

Users

For production workloads involving hundreds or thousands of similarly structured tables, this significantly reduces rerun costs and improves operational efficiency.

This feature represents a major enhancement to SeaTunnel's production governance capabilities.

4.2 PR #10744 — Schema Evolution for File Connectors

PR Size

4 files changed

168 insertions

2 deletions

Background

Traditional file-based sinks generally have poor tolerance for schema changes.

In CDC pipelines, DDL operations such as adding or renaming columns frequently cause downstream writes to fail or produce unreadable files.

By introducing Schema Evolution into the file connector framework, SeaTunnel enables file-based pipelines to adapt to schema changes automatically instead of treating files as static outputs.

Core Design

A new configuration option has been added:

public static final Option<Boolean> SCHEMA_EVOLUTION_ENABLED =
        Options.key("schema_evolution_enabled")
                .booleanType()
                .defaultValue(false)

When enabled, runtime DDL events—including:

• ADD COLUMN
• DROP COLUMN
• RENAME COLUMN
• UPDATE COLUMN

are propagated directly to the file sink.

Rather than mixing incompatible schemas into a single file, SeaTunnel automatically rotates output files whenever a schema boundary is detected.

How It Works

Schema evolution is introduced as an explicit runtime capability through the schema_evolution_enabled option.

Whenever the CDC source emits an ALTER TABLE event, the file sink:

1. Detects the schema change.
2. Finalizes the current output file.
3. Creates a new file using the updated schema.
4. Continues processing without interrupting the pipeline.

This strategy preserves schema consistency while allowing long-running CDC jobs to continue uninterrupted.

Impact

This feature delivers the greatest value for CDC-to-file scenarios, such as:

• MySQL CDC → Parquet
• MySQL CDC → ORC

It also makes downstream analytics significantly easier, since each file now corresponds to a single schema version rather than containing mixed record formats.

More broadly, this enhancement brings file connectors much closer to the schema-aware behavior typically associated with modern streaming data platforms.

4.3 PR #11062: Calcite SQL Transform Plugin Brings a More Powerful Transformation Layer to SeaTunnel

PR Size: 40 files changed, 8,257 insertions(+), 1 deletion(-)

This is one of the largest feature contributions merged in June.

Background

SeaTunnel has long provided transformation capabilities between sources and sinks. However, previous transform operators primarily focused on predefined functionality, making it difficult to express complex business logic or extend SQL capabilities through reusable functions.

As enterprise data pipelines become increasingly sophisticated, users expect a declarative SQL layer capable of handling rich transformations, custom business logic, and extensible function libraries without writing additional processing code.

The introduction of the Calcite SQL Transform Plugin represents a significant step toward that goal.

Rather than adding another transform operator, this PR introduces a unified SQL processing layer powered by Apache Calcite, allowing users to perform more sophisticated data transformations using familiar SQL syntax.

Core Design

At the heart of this implementation is the new CalciteUdf SPI, which defines a standard extension mechanism for user-defined functions.

/**
 * SPI for Calcite SQL transform UDFs. Implementations must provide a public static
 * eval method whose signature determines the SQL function's input/output types.
 */
public interface CalciteUdf

The SPI specifies that every UDF must expose a public static eval() method, allowing Calcite's code generation engine to invoke functions directly without creating object instances.

This design minimizes runtime overhead while providing a clean and standardized extension mechanism.

In addition to the SPI itself, the PR also includes comprehensive documentation, end-to-end tests, sample configurations, and supporting infrastructure, making the feature production-ready rather than an experimental prototype.

How It Works

Instead of hardcoding transformation logic into the engine, SeaTunnel now delegates SQL parsing, optimization, and execution to Apache Calcite.

The plugin architecture enables users to:

• Write more expressive SQL transformations
• Register custom UDFs through the SPI
• Extend built-in SQL functions without modifying the engine
• Share reusable function libraries across projects

By separating SQL execution from connector logic, SeaTunnel establishes a cleaner architecture in which data movement and data transformation evolve independently.

Impact

For users, this dramatically improves the expressiveness of SQL-based data processing. Complex transformations that previously required custom Java development can now be implemented directly in SQL.

For organizations, the standardized UDF extension mechanism makes it easier to encapsulate business logic into reusable function libraries, improving maintainability across multiple data pipelines.

More importantly, this plugin lays the foundation for future enhancements, including richer built-in functions, enterprise UDF ecosystems, and more advanced SQL optimization capabilities.

It represents another important step in SeaTunnel's evolution from a data synchronization framework to a comprehensive data integration platform.

4.4 PR #10812: StateStore Abstraction Marks a Key Architectural Milestone for Zeta

PR Size: 28 files changed, 2,071 insertions(+), 92 deletions(-)

Background

As distributed execution engines evolve, state management becomes one of the most critical architectural components.

Previously, portions of the Zeta engine relied directly on Hazelcast's IMap implementation for state storage. While this approach simplified the initial implementation, it also introduced tight coupling between engine logic and a specific storage technology.

Over time, this coupling becomes architectural debt.

Supporting alternative state backends, introducing hybrid storage strategies, or implementing specialized capabilities such as TTL management becomes increasingly difficult when upper-layer components depend directly on Hazelcast APIs.

This PR addresses that challenge by introducing a generic StateStore abstraction.

Core Design

Rather than exposing Hazelcast semantics throughout the engine, the implementation introduces a hierarchy of capability-oriented interfaces.

public interface ExpiringStateStore<K, V> extends StateStore<K, V>

Additional interfaces include:

• StateStore
• ExpiringStateStore
• IterableStateStore
• Other capability-specific abstractions

Instead of programming against a concrete storage implementation, upper-layer components now depend only on the capabilities they require.

This follows a classic interface-oriented architecture that significantly improves extensibility.

How It Works

The new abstraction separates storage capabilities into independent interfaces.

For example:

• Basic key-value storage is defined by StateStore
• TTL-aware storage is represented by ExpiringStateStore
• Iterable storage capabilities are provided independently
• Additional storage features can be introduced without affecting existing implementations

This modular design prevents Hazelcast-specific concepts from leaking into the rest of the execution engine.

As a result, storage implementations become interchangeable while the engine itself remains largely unchanged.

Impact

Although end users may not notice immediate behavioral differences, this is one of the most strategically important architectural improvements merged in June.

The new abstraction establishes the foundation for future capabilities such as:

• Alternative state storage backends
• Hybrid storage architectures
• Independent state services
• More sophisticated TTL management
• Distributed counters
• Enhanced recovery mechanisms

In other words, this PR is less about adding visible features and more about enabling the next generation of Zeta's architecture.

4.5 PR #10485: BigQuery Sink Further Expands SeaTunnel's Cloud Data Warehouse Ecosystem

PR Size: 40 files changed, 3,169 insertions(+), 1 deletion(-)

Background

As cloud-native data platforms continue to gain adoption, seamless integration with major cloud data warehouses has become increasingly important.

For organizations running workloads on Google Cloud Platform, BigQuery is often the analytical database of choice. Until now, exporting data into BigQuery required additional tooling or custom integrations.

The new BigQuery Sink closes this gap by making BigQuery a first-class destination within the SeaTunnel ecosystem.

Importantly, this PR goes far beyond simply adding another connector.

It includes configuration definitions, serialization logic, error handling, documentation, plugin registration, and integration support, providing a complete production-ready implementation.

Core Design

The connector introduces a dedicated configuration class:

public class BigQuerySinkOptions {

    public static final String IDENTIFIER = "BigQuery";

    public static final Option<String> PROJECT_ID =
            Options.key("project_id")

The configuration allows users to specify essential BigQuery settings such as project information while integrating seamlessly with SeaTunnel's existing connector framework.

How It Works

The connector leverages SeaTunnel's unified Connector-V2 architecture, allowing users to write data into BigQuery using the same configuration model shared across the entire connector ecosystem.

This consistent design minimizes the learning curve while simplifying deployment and maintenance across heterogeneous data platforms.

Impact

The addition of the BigQuery Sink further strengthens SeaTunnel's support for modern cloud-native data architectures.

Organizations operating in multi-cloud or hybrid-cloud environments can now integrate BigQuery into their data pipelines more naturally, reducing the need for custom development and improving interoperability across cloud services.

Beyond the connector itself, this contribution reflects the community's continued investment in expanding SeaTunnel's cloud ecosystem while maintaining a consistent and unified user experience.

5. How Should These Improvements Be Evaluated?

Unlike traditional performance-oriented releases, most of the major changes merged in June were not designed to increase throughput or reduce latency. Instead, they focused on improving governance, reliability, extensibility, compatibility, and operational resilience.

As a result, evaluating these enhancements requires a different set of metrics. Looking only at rows per second or execution latency would fail to capture their real value.

Instead, each feature should be validated according to its intended purpose.

Table-Level Fault Isolation (PR #10600)

For table-level fault isolation, the focus should be on operational efficiency rather than raw performance.

Recommended evaluation metrics include:

• The percentage of tables that continue to complete successfully when one or more tables fail
• The completeness and accuracy of recorded failure information
• The reduction in recovery time and rerun costs
• The effectiveness of failure isolation in large-scale multi-table synchronization jobs

These indicators better reflect how the feature improves production reliability.

Schema Evolution for File Connectors (PR #10744)

Schema evolution should be evaluated based on pipeline continuity and data correctness.

Key validation metrics include:

• Whether CDC pipelines continue running after DDL changes
• Whether output files are correctly rotated at schema boundaries
• Whether downstream analytics systems can continuously consume generated files
• Whether schema versions remain consistent across file partitions

The primary objective is ensuring uninterrupted data delivery while preserving schema consistency.

Calcite SQL Transform Plugin (PR #11062)

For the SQL transformation framework, evaluation should focus on functionality and extensibility rather than execution speed alone.

Important validation areas include:

• Expressiveness of complex SQL transformations
• Ease of developing and registering custom UDFs
• Success rate of end-to-end SQL execution
• Compatibility with existing transformation workflows
• Stability of plugin loading and function discovery

These measurements demonstrate whether the new SQL layer can support increasingly sophisticated business scenarios.

StateStore Abstraction (PR #10812)

Since the StateStore abstraction is primarily an architectural enhancement, validation should emphasize compatibility and maintainability.

Recommended evaluation metrics include:

• Stability of state recovery workflows
• Compatibility across different StateStore implementations
• Regression testing results after replacing storage backends
• Correctness of capability-oriented interface implementations
• Overall engine stability during failover and recovery

Ultimately, the success of this change lies in enabling future evolution without disrupting existing functionality.

Taken together, these improvements highlight an important shift in how SeaTunnel should be evaluated.

Rather than focusing exclusively on throughput benchmarks, June's work demonstrates growing maturity in areas such as reliability testing, disaster recovery, configuration compatibility, end-to-end validation, and production governance. These qualities are often the deciding factors for enterprise adoption.

6. Looking Ahead: Where Is Apache SeaTunnel Heading?

The technical work completed in June reveals a clear direction for the project's evolution.

While connector expansion remains important, the community is increasingly investing in the foundational capabilities required by modern enterprise data platforms.

Evolving Beyond a Connector Framework

SeaTunnel has long been recognized for its broad connector ecosystem. However, recent developments show that the project is expanding well beyond data movement.

Features such as Schema Evolution, the Calcite SQL Transform Plugin, table-level fault isolation, and the StateStore abstraction all extend beyond the scope of individual connectors.

Together, they form the building blocks of a more comprehensive data integration platform capable of handling not only data ingestion, but also transformation, governance, recovery, and lifecycle management.

Strengthening Zeta as an Enterprise Execution Engine

The Zeta engine continues to mature into a more intelligent and manageable execution platform.

Recent improvements—including reporting of non-terminal job states, task workload monitoring, StateStore abstraction, enhanced recovery mechanisms, and expanded operational documentation—demonstrate a growing emphasis on observability, resilience, and operational governance.

These capabilities are essential for organizations running large-scale production workloads, where stability and recoverability are just as important as execution performance.

Documentation Is Becoming a Strategic Asset

Another notable trend is the community's increased investment in documentation.

The high proportion of documentation-related pull requests in June does not simply reflect more written content. Instead, it represents a deliberate effort to capture and share operational knowledge that was previously scattered across code, discussions, and individual experience.

Topics such as StateStore architecture, CDC production best practices, recovery workflows, and REST API lifecycle management are now documented in a more systematic way.

For users, this reduces the learning curve and accelerates production adoption.

For contributors, it establishes a stronger foundation for future collaboration.

For the community as a whole, it makes Apache SeaTunnel more accessible, maintainable, and sustainable.

Final Thoughts

With continued innovation across the engine, connectors, and developer experience, Apache SeaTunnel is becoming more powerful, more reliable, and easier to adopt. Thanks to every contributor who helped shape the project throughout June—we look forward to building an even stronger ecosystem together.