Durable Workflow Orchestration
Temporal vs Cadence (Uber Cadence): what are the practical differences today (features, ecosystem, and migration effort)?
9 min read
Most teams asking about Temporal vs Cadence aren’t debating the theory of workflow engines; they’re deciding whether to keep a Cadence cluster alive, modernize to Temporal, or bet their next platform on one of them. The short version: Cadence was the right idea at Uber; Temporal is that idea generalized, simplified, and battle‑tested for everyone else—with a larger ecosystem, more features, and a much easier operational story.
Quick Answer: Temporal and Uber Cadence share the same durable execution model and many APIs, but Temporal has become the actively developed, community‑driven successor with richer features, better tooling, Temporal Cloud, and a stronger ecosystem. Migrating from Cadence to Temporal is usually incremental and mechanical, not a full rewrite.
Frequently Asked Questions
What’s the core difference between Temporal and Cadence today?
Short Answer: Cadence is the original engine we built at Uber; Temporal is the next‑generation, open‑source Durable Execution platform that took those ideas, removed the Uber‑specific assumptions, and has since evolved much faster in features, stability, and ecosystem.
Expanded Explanation:
Cadence and Temporal share a common lineage: same authors, same core idea—durable execution via replayable Workflows and Activities, persisted event histories, and deterministic execution. In both systems, you write your business logic as code, and the engine makes sure it runs to completion despite crashes, timeouts, or outages.
The divergence is everything around that core. Cadence was optimized for Uber’s environment and constraints. Temporal was created to be a general‑purpose platform: simpler to operate, SDK‑first, cloud‑ready, and open to any organization. Over the last several years, most innovation has gone into Temporal: new SDKs (TypeScript, Python, .NET), Temporal Cloud, better visibility tools, schedules, search attributes, multi‑region story, stronger compatibility guarantees, and a much broader community. Cadence is effectively “frozen at Uber’s needs,” while Temporal is where the active development, ecosystem, and long‑term roadmap live.
Key Takeaways:
- The execution model is similar, but Temporal is the actively maintained, general‑purpose evolution of Cadence.
- If you’re starting fresh in 2026, you should assume Temporal—not Cadence—is the platform that will keep moving with you.
How do I migrate an existing Cadence system to Temporal in practice?
Short Answer: Migration is usually done in phases: align SDKs and domains, stand up Temporal alongside Cadence, dual‑run or gradually cut over Workflows, then decommission Cadence once all critical flows are safely moved.
Expanded Explanation:
Because the same core team built both systems, we intentionally kept APIs and semantics close enough that migration is more about plumbing than rewriting business logic. You don’t throw away your Workflows; you re‑point them. The effort tends to fall into three buckets:
- Concept mapping: Cadence “domains” → Temporal “namespaces,” Cadence service endpoints → Temporal Frontend, Cadence clients → Temporal SDKs/clients. Most familiar concepts (Workflows, Activities, task lists/queues, signals) carry over cleanly.
- Operational cut‑over: Run Temporal alongside Cadence, start new Workflows on Temporal, and let existing Cadence workflows finish where they are. For critical systems, teams often dual‑run, validating behavior and metrics before flipping traffic.
- Feature alignment: Take advantage of Temporal‑only features—like richer search attributes, Web UI improvements, schedules, and Temporal Cloud—but this can be incremental, after you’re stable.
For many organizations, the heaviest lift is not code changes; it’s planning a safe, observable cut‑over of long‑running flows. Temporal’s visibility and replay mechanics make it easier: you can inspect and compare behavior instead of guessing from logs.
Steps:
- Inventory and map: List your Cadence domains, Workflows, Activities, and task lists; map them to Temporal namespaces and task queues.
- Stand up Temporal: Either deploy open‑source Temporal or spin up Temporal Cloud; integrate the Temporal SDKs into your services.
- Gradual cut‑over: Start routing new Workflow executions to Temporal, allow in‑flight Cadence executions to complete, and then retire Cadence domains once traffic has drained.
How do Temporal and Cadence compare on features, tooling, and ecosystem?
Short Answer: Temporal extends the Cadence model with more language SDKs, Temporal Cloud, stronger visibility tooling, richer search and scheduling primitives, and a larger open ecosystem of integrations and production adopters.
Expanded Explanation:
Cadence gave you the core: durable workflows, replay, and Activities. Temporal keeps that core and adds a lot around it aimed at everyday development and operations.
Some highlights that matter in practice:
- SDK coverage and ergonomics: Temporal has official SDKs for Go, Java, TypeScript, Python, and .NET, with ongoing investment in developer experience. Cadence is mostly centered on Go and Java, with slower evolution and fewer modern language features.
- Temporal Cloud: With Temporal, you can choose: self‑host the open‑source Service or let us run it as Temporal Cloud—“reliable, scalable, serverless Temporal in 11+ regions”—while keeping your Workers (your code) in your own environment. Cadence has no managed offering; you own all ops.
- Visibility & debugging: Temporal’s Web UI, search attributes, and Workflow inspection capabilities are built for day‑2 operations: find a Workflow by business key, inspect its full execution history, replay, and even “rewind” from an intermediate point. Cadence has UI tooling, but it’s less polished and less actively developed.
- Schedules & timers: Temporal leans into “Schedule, don’t Cron.” You get first‑class schedules, durable timers, and long waits that survive outages (“wait for 3 seconds or 3 months” without losing state). Cadence has timers, but Temporal’s scheduling stack and operational controls are more mature.
- Ecosystem and community: Temporal is MIT‑licensed, 100% open source, with ~19k GitHub stars, 14,000+ community members, and 1,500+ customers running 130B+ monthly actions—everyone from NVIDIA and Salesforce to fintechs and AI companies. That ecosystem shows up as recipes, frameworks, agentic AI patterns, and integrations (OpenAI, Pydantic, Vercel, etc.) that simply don’t exist around Cadence.
Comparison Snapshot:
- Option A: Cadence (Uber Cadence): Proven durable execution engine tailored to Uber’s environment; limited language coverage; fully DIY operations; slower ecosystem and feature velocity.
- Option B: Temporal: General‑purpose, actively developed Durable Execution platform with multiple SDKs, better tooling, Temporal Cloud option, and a large open community and partner ecosystem.
- Best for: Any team that wants durable, long‑running workflows as a core primitive, with the confidence that the platform will keep evolving and won’t become another internal, frozen dependency.
How does day‑to‑day implementation differ between Temporal and Cadence?
Short Answer: Implementing with Temporal feels like writing normal application code with durable primitives and better tooling; with Cadence you get the same core concepts, but less DX polish, less operational visibility, and no managed service option.
Expanded Explanation:
At the code level, the mental model is shared: you define Workflows and Activities, you rely on deterministic execution, and you let the engine handle retries, state persistence, and recovery. The difference is how it feels to ship and operate that code.
With Temporal, we’ve put most of our energy into “developer‑first Durable Execution”: language‑native SDKs, clearer type systems, better testing harnesses, and a Web UI you can hand to operators and support teams. Teams build order fulfillment, money movement, CI/CD rollbacks, infra provisioning, and increasingly AI pipelines and agentic systems—all as normal code—with the Temporal Service orchestrating execution. When something breaks, they use the Web UI to search by Workflow ID or business key, inspect the event history, replay, and debug without guesswork.
Operationally, you also choose your hosting path:
- Self‑hosted Temporal: You deploy the Temporal Service in your environment, similar in spirit to running Cadence—but with more docs, patterns, and community knowledge to lean on.
- Temporal Cloud: You keep all Workers (your code) in your environment. The Temporal Service runs in our cloud, in 11+ regions, scaling and staying available through outages. Connections are unidirectional; either way, we never see your code.
Cadence gives you the base engine but not these newer operational choices or DX features. You’ll often find yourself re‑implementing pieces that Temporal now provides out of the box.
What You Need:
- For Temporal: Access to one of the supported SDKs, a connection to a Temporal Service (self‑hosted or Temporal Cloud), and a clear mapping of your long‑running processes into Workflows and Activities.
- For Cadence: The same conceptual work, plus ownership of the Cadence service lifecycle, upgrades, and any UI/observability layers you need on top.
Strategically, why should a team standardize on Temporal instead of staying on Cadence?
Short Answer: Temporal lets you treat reliability as a primitive, not custom glue—backed by an active roadmap, managed service option, and a broad community—while Cadence is effectively locked to Uber’s trajectory and your own operational capacity.
Expanded Explanation:
The real question isn’t “Can Cadence work?” It clearly can; Uber runs it at massive scale. The question is: Do you want your core reliability primitive to be a fork of Uber’s internal engine, or a platform whose entire purpose is Durable Execution for everyone?
Without Temporal, teams on Cadence tend to accumulate:
- DIY operations: upgrades, scaling, multi‑region failover, and security posture are all on you.
- Fragmented tooling: homegrown dashboards, custom admin scripts, ad‑hoc log queries to debug stuck workflows.
- Feature inertia: adopting new languages, integrating with new frameworks, and building AI‑heavy or cross‑cloud systems means more in‑house engineering.
With Temporal, you get:
- A single, evolving Durable Execution platform that already powers mission‑critical workloads at NVIDIA, Salesforce, Netflix, Twilio, and many others.
- A choice of deployment model (self‑hosted OSS or Temporal Cloud), so you can offload as much or as little infrastructure as you want.
- A community and ecosystem that mean you’re rarely the first to hit a given scale, failure mode, or pattern.
In other words, Temporal is designed so that “APIs fail, networks flake, and services crash” is just a fact of life, not an emergency. You write your backend logic as code, and the platform makes sure it completes—no lost progress, no orphaned processes, and no manual recovery runs.
Why It Matters:
- Long‑term leverage: Temporal turns cross‑service, long‑running logic into durable, testable code with a clear, supported upgrade path, instead of leaving you with an aging internal fork.
- Reduced operational drag: You spend less time firefighting and more time shipping features, because retries, state, timeouts, and recovery are handled by a platform used and improved by thousands of teams—not re‑implemented by yours.
Quick Recap
Cadence and Temporal share the same DNA: durable Workflows, Activities, and replay‑based recovery. Temporal is that model taken to its logical conclusion: a general‑purpose, open, and actively developed Durable Execution platform with multiple SDKs, a strong ecosystem, full visibility tooling, and a managed offering in Temporal Cloud. Migrating from Cadence to Temporal is usually an incremental, mechanical process—mapping domains to namespaces, re‑pointing clients, and gradually cutting over Workflow traffic—rather than a rewrite. If you’re choosing where to place your next decade of backend reliability, Temporal is the platform built for that future.