dtm
DTM is a distributed transaction framework written in Go that handles data consistency across microservices using patterns like Saga, TCC, and XA. It provides SDKs for multiple languages (Go, Java, PHP, C#, Python, Node.js) and supports various databases including MySQL, PostgreSQL, MongoDB, and Redis.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | dtm-labs/dtm |
| Owner | dtm-labs |
| Primary language | Go |
| License | BSD-3-Clause — OSI-approved |
| Stars | 10.9k |
| Forks | 999 |
| Open issues | 87 |
| Latest release | v1.19.0 (2025-02-04) |
| Last updated | 2026-01-03 |
| Source | https://github.com/dtm-labs/dtm |
What dtm is
DTM is a Go-based distributed transaction coordinator that implements saga, TCC, XA, 2-phase message, outbox, and workflow patterns for cross-service eventual consistency. It uses pluggable storage engines (MySQL, Redis, BoltDB, MongoDB) and provides language-agnostic SDKs via gRPC/HTTP interfaces.
Get the dtm source
Clone the repository and explore it locally.
git clone https://github.com/dtm-labs/dtm.gitcd dtm# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Requires explicit compensation logic for each transaction branch; application code must implement reversal operations or risk data inconsistency.
- DTM server must be deployed and operated as a separate service with its own database; adds operational complexity and potential single point of failure unless clustered.
- Idempotency is critical: all compensating operations and forward operations must be idempotent to handle retries safely.
- Network latency and service availability directly impact transaction completion time; design services with reasonable timeouts and retry policies.
- Debugging distributed transaction failures is more complex; requires centralized logging and tracing across all participating services.
When to avoid it — and what to weigh
- Strong ACID requirements within a single database — DTM is designed for eventual consistency across services. Single-database transactions should use native database ACID instead.
- Real-time, sub-millisecond consistency guarantees — DTM uses polling and eventual consistency patterns. Systems requiring immediate strong consistency across all nodes are not a good fit.
- Your team lacks Go expertise or microservice architecture experience — DTM requires understanding of distributed transaction patterns, compensation logic, and operational complexity. Poor implementation can create subtle data consistency bugs.
- Small, tightly-coupled monolithic applications — The overhead of DTM is not justified for single-service systems; use native database transactions instead.
License & commercial use
Licensed under BSD-3-Clause (BSD 3-Clause 'New' or 'Revised' License), a permissive OSI-approved license allowing modification and distribution with conditions.
BSD-3-Clause is a permissive license generally compatible with commercial use. However, verify your organization's legal review of BSD-3-Clause terms (including liability disclaimer and attribution) before production deployment. No warranty or liability guarantee is provided by the license.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | High |
| DEV.co fit | Good |
| Assessment confidence | High |
DTM itself does not appear to claim encryption, authentication, or authorization in provided materials. When operating DTM in production, ensure: network communication between DTM server and services is protected (TLS), database credentials are secured, DTM server has network isolation, and audit logging is enabled. Verify security posture of any publicly exposed DTM endpoints. No security audit details provided in source materials.
Alternatives to consider
Temporal / Cadence
More mature workflow-as-code platforms with built-in UI and monitoring; better for complex, long-running orchestration; heavier operational footprint.
Apache Camel / Debezium
Event streaming and CDC-based consistency; better for log-based architectures; less integrated transaction coordination than DTM.
Seata
Similar distributed transaction framework with Saga/TCC/XA support; primarily Java ecosystem; different maturity and community size.
Build on dtm with DEV.co software developers
DTM provides battle-tested patterns for cross-service consistency. Contact us to assess whether DTM fits your microservice architecture, or to design integration and operational plans for production deployment.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
dtm FAQ
Does DTM require all microservices to be rewritten?
What happens if the DTM server goes down?
Is DTM suitable for financial transactions?
What languages can use DTM?
Software developers & web developers for hire
DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If dtm is part of your open-source databases roadmap, our team can implement, customize, migrate, and maintain it.
Evaluate DTM for Your Distributed Transaction Needs
DTM provides battle-tested patterns for cross-service consistency. Contact us to assess whether DTM fits your microservice architecture, or to design integration and operational plans for production deployment.