# Apache Seata (incubating): distributed transactions across microservice data sources

> Seata coordinates global transactions over services that each own a separate database, using TC, TM and RM roles around an XID. This review covers its transaction lifecycle, Maven setup, the AT mode trade-offs, and where Saga or TCC fits better.

**apache/incubator-seata** — :fire: Seata is an easy-to-use, high-performance, open source distributed transaction solution.

- Repository: https://github.com/apache/incubator-seata
- Website: https://seata.apache.org/
- Stars: 26,011 · Forks: 8,848
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-incubator-seata

## The monolithic transaction that stops working when you split the database

Seata targets one specific failure. In a monolith, three business modules write to a single local data source, and the local transaction covers all of them. Split those modules into three services on three data sources, the pattern the README points to as database per service, and each service still gets a correct local transaction. The business operation as a whole does not. There is no single connection to commit or roll back, so a failure halfway through leaves two services committed and one not.

The README frames the audience directly: a distributed transaction solution for microservices architecture, written in Java. That is the whole scope. It is not a message queue, not a saga orchestrator for non-Java services, and not a replacement for careful service boundaries. If your operation already fits inside one database, Seata adds a coordinator, a client library and extra tables for nothing.

The project has a long commercial lineage. The README's History section traces TXC at Alibaba from 2014, GTS as the Aliyun middleware product from 2016, Fescar as the open source project from 2019, and the merger with Ant Financial's XTS and DTX work that produced the Seata name. Apache Seata entered the Apache Incubator in October 2023, which is why the repository and release names still carry the incubating label.

## TC, TM and RM: how a global transaction is actually driven

The architecture has three roles, and the split matters when you are deciding what to deploy. The Transaction Coordinator (TC) is a server process. It keeps the status of global and branch transactions and drives the final commit or rollback. The Transaction Manager (TM) is the piece inside your application that defines the scope: it begins a global transaction, then asks for commit or rollback. The Resource Manager (RM) manages the resources a branch transaction touches, registers the branch with the TC, reports its status, and drives the branch commit or rollback.

The lifecycle is five steps, and the XID is the thread that runs through them. The TM asks the TC to begin a global transaction, and the TC generates an XID for it. That XID propagates through the microservice invoke chain. Each RM registers its local transaction as a branch of the global transaction identified by that XID. The TM then asks the TC to commit or roll back. Finally the TC drives every branch under that XID to finish its branch commit or rollback.

The consequence for operations is concrete. The TC is stateful infrastructure that sits between your services and their outcome. It is a separate process to run, monitor and give durable storage. The repository's top-level layout reflects this: server/ holds the coordinator, namingserver/ and discovery/ cover how clients find it, config/ covers configuration storage, and console/ is a management surface. Modes such as AT, TCC and Saga live in rm-datasource/, tcc/ and saga/ respectively, so the transaction mode is a choice of module, not a runtime flag you flip casually.

## Installing Seata from Maven and running a first global transaction

Seata is a library plus a server, not a standalone binary you start and point at a database. The README says to pick one of two dependencies depending on the scenario: org.apache.seata:seata-all for non-Spring Boot frameworks, or org.apache.seata:seata-spring-boot-starter for Spring Boot projects. The README notes that seata-spring-boot-starter already includes seata-all, so you do not declare both.

```xml
<properties>
  <seata.version>2.5.0</seata.version>
</properties>

<dependencies>
  <dependency>
    <groupId>org.apache.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>${seata.version}</version>
  </dependency>
</dependencies>
```

After adding the dependency, you need a running TC for the client to talk to. The README's Quick Start points to the deploy guide on the official site rather than repeating the steps, and the repository root carries a Makefile whose targets are the project's own build entry points. The help target lists them, which is the fastest way to see what the build offers before you run anything.

```bash
make help
```

That prints the documented targets and their descriptions, including the server and naming server install and run targets. The README does not document the individual configuration keys for connecting a client to the TC, so treat the official deploy guide as the source for the registry and config settings rather than guessing at property names. For a first real use, the shape is: start the TC, configure your application to register with it, wrap the business method that spans services in a global transaction, and make sure each participating schema has whatever table the chosen mode requires. The README does not show a worked end-to-end example, so the first integration will be driven by the deploy guide and the module you pick.

## The AT mode trade-off: automatic rollback in exchange for undo logs and SQL limits

The repository splits transaction modes into modules, and the README's core concepts explain why the default one is attractive. A branch transaction is typically a local transaction, and the RM drives its commit or rollback. In the AT mode the client intercepts the SQL, records before and after images, and can roll a branch back without you writing a compensating method. That is the selling point: business code looks almost like ordinary local transactions.

The cost is not hidden but it is easy to underestimate. Rollback needs something to roll back from, which means undo records stored alongside your data, which means schema changes in every participating database. The README does not spell out the undo table DDL, so you will be reading the deploy guide and the rm-datasource module rather than the front page. The second cost is SQL coverage. An interception-based mode has to understand the statements it rewrites. The repository carries a dedicated sqlparser/ module, which tells you parsing is a first-class concern here and therefore a place where an unusual statement can become your problem.

The third cost is the TC itself. It is the component that decides the outcome, so it is also the component whose unavailability stalls transaction resolution. The README describes the roles and the lifecycle but does not document what happens to in-flight global transactions when the TC is unreachable. That is a gap worth closing with your own failure testing before production, not something the front page answers.

## When Seata is the wrong tool, and what to reach for instead

Seata is the wrong tool when the operation fits one data source. Adding a coordinator, a client and undo tables to a transaction that a single database already handles correctly is pure overhead.

It is also the wrong tool when your services are not Java. The entire client surface here is Java: the README's dependency section is Maven, the modules are Java, and the primary language is Java. The repository does list integration-tx-api/, which suggests a path for integrating other transaction APIs, but the README does not present a polyglot client story, so a mixed stack should be treated as unproven from this material.

For long-running business processes with human steps, a workflow engine is a better fit than a distributed transaction. Temporal and Camunda model a process as durable steps with retries and compensation, and they do not need a coordinator holding branch state in the middle of your request path. The difference in approach is the unit of work: Seata's unit is a database transaction spanning services, held open briefly; a workflow engine's unit is a process that can run for days and whose steps are ordinary service calls. If your operation involves waiting on a person or an external system, Seata is the wrong shape.

Saga inside Seata is the middle ground and is worth naming separately. It is one of the modes the repository ships, in saga/, and it trades atomicity for a sequence of local transactions with compensating actions you write. That is the honest choice when you cannot hold a global transaction open, but it moves correctness work back into your application code.

## Maintenance, release cadence and the Apache-2.0 licence

The default branch is 2.x and the last push was on 2026-09-20. Releases are not frequent: v2.5.0 landed on 2025-07-21, v2.6.0 on 2026-01-28, and v2.7.0 is labelled a release candidate on 2026-09-06. That cadence is worth planning around. If you adopt a version, expect to sit on it for months between upgrades, and read the changes/ directory and the release notes before moving, because a distributed transaction client is not a dependency you bump casually.

The upgrade cost is structural rather than just version-numbered. The version appears in your build as a property, so the mechanical part is a one-line change. The real cost is that the client, the TC server and the branch-side tables need to move together. A client on a newer version talking to an older TC, or undo tables whose layout does not match what the client expects, is the kind of mismatch that only shows up under failure. The README does not document a mixed-version compatibility matrix, so verify that before planning a rolling upgrade.

The licence is Apache-2.0, and the repository carries the standard Apache files: LICENSE, NOTICE, DISCLAIMER and .licenserc.yaml. The DISCLAIMER file exists because the project is in the Apache Incubator, which means the governance and release process is still maturing under the foundation. Apache-2.0 is permissive and includes a patent grant, but this is a description of the licence text, not legal advice for your situation. If you redistribute Seata inside a product, read the NOTICE and DISCLAIMER files yourself.

## Conclusion

Adopt Seata when your Java services each own a database and a business operation spans several of them, and you accept an extra coordinator process plus undo-log tables in your schemas. Do not adopt it if your writes already fit one local transaction, or if you cannot operate a TC cluster and its storage. Before committing, verify the AT mode against your actual SQL: check whether the statements you run are supported, confirm the undo_log table exists in every participating schema, and run one failure case end to end to see the branch rollback actually fire.

## FAQ

### What is Apache Seata used for?

It coordinates a distributed transaction across microservices that each own a separate data source, where no single local transaction can cover the whole business operation. The README describes it as a distributed transaction solution for microservices architecture, built around a global transaction made of branch transactions.

### Which Maven dependency should I add for Seata?

The README says to choose one of two: org.apache.seata:seata-all for non-Spring Boot applications, or org.apache.seata:seata-spring-boot-starter for Spring Boot projects. The README notes that seata-spring-boot-starter already includes seata-all, so you do not add both.

### Do I need to run a separate Seata server?

Yes. The Transaction Coordinator is a server process that maintains the status of global and branch transactions and drives the final commit or rollback. The repository keeps it in the server/ module, with namingserver/ and discovery/ covering how clients locate it.

## Sources

- [apache/incubator-seata on GitHub](https://github.com/apache/incubator-seata)
- [License: Apache-2.0](https://github.com/apache/incubator-seata/blob/2.x/LICENSE)
- [Project website](https://seata.apache.org/)
- [README](https://github.com/apache/incubator-seata/blob/2.x/README.md)
- [Releases](https://github.com/apache/incubator-seata/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-incubator-seata