Temporal vs Cadence: which to choose

Temporal or Cadence: when each one fits a durable execution shortlist

Teams choosing a durable execution engine for long-running business or application workflows should first decide who will operate the cluster. Temporal fits teams that want an MIT-licensed server with the option of Temporal Cloud, a managed service sold by Temporal Technologies. Cadence fits teams that prioritize an Apache-2.0 project under open governance of the Cloud Native Computing Foundation. Four factors usually decide the choice: managed versus self-hosted operation, the SDK languages your engineers already use, the persistence and visibility stores your organization has standardized, and your governance preference.

The operating model and storage choices are where the trade-offs become concrete. Both engines run a multi-service backend on a database, so check whether your standard database is on each list. Temporal tests Cassandra, PostgreSQL and MySQL for persistence, while Cadence supports Cassandra, MySQL or PostgreSQL, optionally with Kafka and Elasticsearch. For visibility, Temporal recommends Elasticsearch or OpenSearch once workflow volume grows beyond a few executions, so confirm that your team can run a search tier. On languages, Temporal workflows are written in Go, Java, TypeScript or Python, while Cadence has official Go and Java SDKs and only community Python and Ruby SDKs. A team whose services are mainly Python or TypeScript will find Temporal's language coverage easier to justify, and a Go or Java team with a strict Apache-2.0 requirement will find Cadence easier to approve.

Governance and the managed option settle the rest. Temporal Cloud is priced on usage, so ask Temporal for a quote based on your expected action volume and storage retention, then compare that figure with the staff time a self-hosted cluster will consume. This page does not confirm a managed Cadence offering, so ask Cadence maintainers and hosting providers what operated options exist before you assume one. Also compare release cadence: Cadence v1.4.2 was published on October 2, 2026, and Temporal Server v1.32.1 on October 8, 2026, so request each project's upgrade and support policy in writing. A practical next step is a short scoring sheet covering languages, database standard, managed-service requirement and governance rule, reviewed by the engineers who will carry the pager.

Which platform fits which scenario

This table maps common team situations to the platform that usually fits better, along with the condition that makes that choice hold. Read each row as a starting point and check the condition against your own estate, licensing rules and operating model before you decide. Most rows turn on managed operations, governance requirements, SDK languages and the databases your organization already runs.

Scenario	Better fit	Condition that makes it so
Managed-first team with no Kubernetes operations staff	Temporal	Temporal Cloud is a managed service sold by Temporal Technologies, so the team does not run the server cluster. Ask any Cadence provider whether a managed offering exists and what it covers.
CNCF governance is a procurement requirement	Cadence	Cadence is a CNCF project under the Cloud Native Computing Foundation's open governance. Temporal is MIT licensed and stewarded by Temporal Technologies, so confirm whether your policy accepts that model.
Go or Java-only estate	Either	Both platforms have official Go and Java SDKs. Choose on governance and operations, because the language gap does not separate them for this estate.
Existing Cassandra standard	Cadence	Cassandra is a supported Cadence backend alongside MySQL and PostgreSQL. Temporal tests Cassandra too, but its Cassandra visibility store was removed in version 1.24, so plan a separate visibility store.
Existing MySQL standard	Either	Both platforms can persist to MySQL. Temporal tests MySQL 5.7 and 8.0.19 or later, so check the Cadence version and MySQL release your team would pin.
Polyglot team needing several SDK languages	Temporal	Temporal workflows are documented in Go, Java, TypeScript and Python. Cadence has official Go and Java SDKs, with community Python and Ruby clients that your team would need to assess.
Access control set up before launch	Temporal	Temporal documents mTLS, a ClaimMapper, an Authorizer plugin and OIDC single sign-on for the Web UI. Its default authorizer allows every request until you configure one.

How Temporal and Cadence are built and deployed

Both engines split a durable execution platform into a server cluster, a database and workers that hold the workflow code. The differences that matter for operations sit in how many services you run, which stores you must provision and how each project ships its deployment tooling.

Temporal Service process layout

A self-hosted Temporal Service runs Frontend, History, Matching and Worker services, each scaled and monitored separately. Frontend receives API calls, History holds workflow state, and Matching dispatches tasks to workers. Ask your team who will own each service's sizing, upgrades and alerting before you commit to self-hosting, because the platform is more than one binary.

Temporal persistence and visibility stores

Temporal needs a persistence store for workflow state and a separate visibility store for search. Persistence is tested on Cassandra, PostgreSQL and MySQL, and SQLite is for development only. Visibility can run on Elasticsearch or OpenSearch, which Temporal recommends beyond a few workflow executions. Confirm which pair your platform team can back up and restore.

Cadence backend services and stores

Cadence runs multiple backend services over a Cassandra, MySQL or PostgreSQL database, with Kafka and Elasticsearch as optional components. Those optional pieces change the footprint quickly, so Cadence deployments often differ in size from one team to another. Before you compare hardware, ask the Cadence community or your own architects which combination of database, Kafka and Elasticsearch you intend to run.

Deployment paths for Temporal

Temporal offers Docker Compose, Go binaries, Helm charts that place each server service in its own Kubernetes pods, and a custom Go build that imports the server package. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so pin chart and image versions together. Choose the path your operators already automate, not the quickest demo.

Official Helm chart for Cadence

Cadence publishes an official Helm chart in the cadence-charts repository, and the project documents a Google Kubernetes Engine codelab that uses PostgreSQL, Kafka and OpenSearch for advanced visibility. Treat the codelab as a reference architecture to adapt, not a sized production profile. Ask whether your Kubernetes platform already supports the chart's storage and ingress assumptions.

Workers hold the workflow code

In both engines, workers, not the server, execute the workflow and activity code written in an SDK. Temporal workers are typically written in Go, Java, TypeScript or Python, while Cadence has official Go and Java SDKs and community Python and Ruby SDKs. Plan worker deployment, versioning and rollout as application releases, and confirm the SDK support your language teams need.

Side-by-side: SDKs, persistence, visibility, security and licensing

This table compares Temporal and Cadence on the capabilities that shape day-one decisions: license, SDKs, persistence, visibility, authorization defaults, transport security and managed options. Where a row shows a confirm item, the supplied research does not settle the point, so check it with the vendor or in a proof of concept before you commit. The main takeaway is that Temporal has the more documented self-hosted security controls and a commercial managed service, while Cadence's main draw is its Apache-2.0 license under CNCF governance.

Capability	Temporal	Cadence
License	MIT for Temporal Server, per its GitHub repository	Apache-2.0 for the Cadence repository
Official SDKs	Go, Java, TypeScript and Python	Official Go and Java; community Python and Ruby SDKs (confirm maturity before choosing)
Persistence stores	Cassandra, PostgreSQL and MySQL are tested; SQLite is for development and testing only	Cassandra, MySQL or PostgreSQL, optionally with Kafka and Elasticsearch
Visibility store	Elasticsearch 7 and 8, OpenSearch 2 or later, MySQL 8.0.17+, PostgreSQL 12+ or SQLite from 1.20; Cassandra visibility was removed in 1.24	Optional Elasticsearch for advanced visibility; confirm supported versions and the visibility options current in your target release
Default authorization	If no Authorizer is configured, the noopAuthorizer allows every API request with no authentication	Confirm the default authentication and authorization behavior for your release with the project
mTLS and SSO for the Web UI	mTLS with separate internode and frontend settings, plus OIDC single sign-on for the Web UI	Confirm mTLS and OIDC support for the Web UI and frontend with the maintainers
Payload encryption	Custom codecs and a codec server	Confirm the supported approach with the project
Managed option	Temporal Cloud, with pay-as-you-go pricing and SAML SSO per the pricing page	No managed service identified in the supplied sources; confirm with the project or community providers
Governance	Maintained by Temporal Technologies	CNCF project under open governance; names Uber, DoorDash and NetApp as users

What each license and edition covers

The Temporal Server is licensed under the MIT license, so you can run, modify and redistribute the server code in your own infrastructure without a license fee for the server itself. Temporal Technologies also sells Temporal Cloud as a managed service, which is a separate commercial product rather than a different edition of the open-source server. Its published pay-as-you-go pricing is the reference point for a cloud quote, and the elements you should model are these:

Action pricing: pay-as-you-go pricing starts at 50 US dollars per million actions.
Storage pricing: active storage is billed at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour.
SLA tiers: the published SLA is 99.9%, or 99.99% with high availability.
Single sign-on: SAML SSO is listed on the pricing page.

Confirm current figures on the pricing page before budgeting, since these are list prices and an enterprise agreement may differ. Ask Temporal Technologies which SLA tier, data residency and support terms apply to your account.

How release lines and upgrades affect running a Temporal Server

Running a self-hosted Temporal Server means treating upgrades as a standing operational task. Temporal's guidance is to upgrade one minor version at a time, moving to the latest patch of the current minor first, because backward compatibility is guaranteed only between two successive minor versions. The current line is v1.32, with v1.32.1 published on October 8, 2026. Patch releases v1.31.4 and v1.30.8 followed on October 12, 2026 for earlier minor lines. A team on an older minor line may therefore need several sequential hops rather than one jump, and each hop needs its own validation. Map your current version against the upgrade guide before you schedule anything.

Sequencing also covers the database. When release notes call for it, run schema upgrades before the server upgrade. Self-hosted Temporal separates the Frontend, History, Matching and Worker services from the persistence and visibility stores, so a schema change may touch more than one store, and each one must be rehearsed. Deployment tooling adds another dependency: Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so the chart version belongs in the same change record as the server image. For Cadence, the latest release in the supplied facts is v1.4.2, published on October 2, 2026. Confirm Cadence's own upgrade order, schema steps and supported version pairs in its repository before you compare effort, because the supplied facts do not describe them.

Whichever platform you choose, plan the release process before the first production deployment. Keep a staging cluster that uses the same persistence backend, version and visibility store as production. Rehearse schema changes and server rollouts there, pin every image and chart version, and record a rollback path for each step. Assign an owner to watch release announcements and decide how quickly patches are applied. Ask any vendor or managed provider how they test upgrades, what notice they give, and which steps remain your responsibility.

What drives the running cost of each platform

Running Temporal or Cadence costs more than the license line, which is zero for both self-hosted engines. The real spend sits in the services, the database, the visibility store, the people who operate them, and, for Temporal Cloud, metered usage. The cards below separate one-time setup from recurring operating cost so you can build a like-for-like quote.

Infrastructure for services and database

A self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus a persistence store, and Cadence runs its own set of services with Cassandra, MySQL or PostgreSQL. Both bill recurring compute, storage and network to your cloud account or data center. Ask the quote to state node counts, database sizing, replicas and backup retention separately, since those figures drive the monthly bill more than the engine does.

Visibility store and its sizing

Temporal advanced visibility can run on Elasticsearch or OpenSearch, which adds a second cluster that recurs in compute and storage. Cadence advanced visibility can use Kafka and Elasticsearch, and its Google Kubernetes Engine codelab uses OpenSearch. Ask each vendor or partner which visibility store they recommend for your expected execution volume, and price it as its own line item because it often grows faster than the core services.

Staff skills in Kubernetes and the database

Operating either engine well requires people who know Kubernetes, Helm, the chosen database and the engine's upgrade path. This is recurring labor, often the largest line for a small platform team. Confirm whether your team already runs these skills in production, and whether the quote includes handover training or only deployment.

Upgrades and on-call coverage

Temporal asks operators to move one minor version at a time and to run schema upgrades before server upgrades when release notes require them, which turns each upgrade into a planned change window. Cadence upgrades also need a tested runbook. Budget recurring time for patch releases, upgrade testing and an on-call rota that covers the frontend, history and persistence layers.

Temporal Cloud usage and storage rates

Temporal Cloud pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to Temporal's pricing page. Your bill therefore scales with action volume and with how long workflow histories are kept. Ask for a projection based on your workflow count, retention period and payload sizes, and confirm which costs are metered versus included.

SLA tier and support terms

Temporal Cloud lists a 99.9% SLA, or 99.99% with high availability, which is a contracted tier with a cost difference. Self-hosted operation carries no vendor SLA, so uptime depends on your own on-call and redundancy design. Cadence has no equivalent managed SLA in the supplied facts, so confirm any commercial support terms directly with the provider. Ask every quote to name the SLA tier and the support hours it includes.

Moving a workflow fleet from Cadence to Temporal, or back

This sequence moves a fleet of workflows from one engine to the other without losing track of executions already in flight. It ends with a tested cutover, a retired source system and a written record of what transferred and what was rebuilt.

Inventory workflows, activities and their owners
The team lists every workflow type, activity, signal, query and scheduled start running on the current engine, and records which service owns each one. Platform engineering and the application owners review the list together. The output is a register that captures each workflow's inputs, retry and timeout settings, and the Cadence domain or Temporal namespace it runs in. Confirm the migration path for each item, including whether any tooling exists for the chosen direction, with the vendor before setting a schedule.
Choose the target SDK language
Pick the language for the rebuilt workflow code based on the SDKs the target engine supports and the skills your team already holds. Cadence provides official Go and Java SDKs, with community Python and Ruby SDKs. Temporal workflows are written in Go, Java, TypeScript and Python. A team moving from Cadence to Temporal can keep Go or Java, while a move back to Cadence limits the official options to Go and Java. The step closes with a decision record naming the language for each service, approved by that service's owner.
Rebuild workflow code against the new SDK
Developers port each workflow and activity to the target SDK. Workflow intent, input and output data models and the documented runbooks carry across, while SDK-specific code, deployment manifests and visibility queries are rebuilt for the new engine. Temporal workflows must be deterministic and replay from an ordered event history, so code that reads the clock, random values or external services directly needs to move into activities. The step is done when each ported workflow passes replay or integration tests in a non-production environment and the results are stored with the register.
Plan persistence and visibility stores
Decide where the target engine keeps execution state and where it indexes workflows for search. Temporal's tested persistence options are Cassandra, PostgreSQL and MySQL, with SQLite for development and testing only. Its advanced visibility depends on the server version and can use Elasticsearch, OpenSearch, MySQL, PostgreSQL or SQLite. Cadence uses Cassandra, MySQL or PostgreSQL, with optional Kafka and Elasticsearch. Check the version matrix for your chosen release, and confirm with the vendor whether any visibility data can be carried over. The step closes with a signed storage design and a restore-tested backup plan.
Deploy the target cluster beside the source
Platform engineering stands up the new engine in its own environment with separate persistence, visibility, TLS and identity settings. Temporal's documented deployment paths include Docker Compose, Go binaries, and Helm charts that run each service in its own Kubernetes pod, and Helm chart versions below 0.73.1 do not work with server images 1.30 and later. If no Authorizer is configured, self-hosted Temporal uses the noopAuthorizer, which allows every API request, so authorization must be in place before any application connects. Services should sit on hosts not reachable from the public internet. The step is done when the security review passes and a smoke test workflow runs end to end.
Run both engines for in-flight executions
New workflow starts go to the target engine, while executions already running on the source finish there. Operators watch both systems in parallel, using the source's CLI and web UI alongside the target's tooling, and log every workflow that needs manual intervention. Execution histories are specific to each engine, so confirm with the vendor how a running workflow can or cannot be handled mid-flight before planning around it. The step is done when the source shows no open executions for the retiring workflow types, or each remaining execution has a named owner and a recorded decision.
Cut over and retire the source
When the source is empty or every remaining item has a decision, the team points all clients, schedules and alerts at the target and shuts down the old workers. Runbooks are updated to the new CLI, UI and metrics, and the source's persistence stays under retention until the team agrees it can be deleted. Service owners sign the cutover checklist, dashboards point to the new engine, and the archived backup has been restore-tested before any source data is removed.

Where Temporal and Cadence implementations usually run long

The longest work in either platform is usually the server cluster and its data stores, not the workflow code. A self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus persistence and visibility stores, and the Temporal deployment docs cover Docker Compose, Go binaries, Helm charts that place each service in its own Kubernetes pods, or a custom Go build. Confirm the Helm chart version before you deploy: chart versions below 0.73.1 do not work with server images 1.30 and later. For Cadence, the backend is several services plus Cassandra, MySQL or PostgreSQL, with optional Kafka and Elasticsearch, and the official Helm chart from the cadence-charts repository is the usual starting point. Plan for each of those components to have an owner, an upgrade path and a backup plan before the first production workflow runs.

Persistence and visibility design is where teams most often need to rework decisions. Temporal tests Cassandra, PostgreSQL and MySQL for persistence and treats SQLite as development only. Visibility is a separate store: Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions, and Cassandra visibility was removed in 1.24, so a Cassandra persistence design needs a different visibility store from day one. Confirm which visibility backends your Cadence version and your search requirements support. Changing these choices after launch means a migration project, so settle them during design.

Identity and network placement are the controls auditors and security teams will ask about first. Out of the box, a self-hosted Temporal Service uses the default noopAuthorizer, which allows every API request with no authentication or access control, so an Authorizer must be configured before any shared access. Temporal's self-hosted security controls include mTLS with separate internode and frontend settings, a ClaimMapper that maps JWT or certificate claims to namespace roles, an Authorizer plugin, OIDC single sign-on for the Web UI, and custom codecs with a codec server for payload encryption. The Temporal docs also say services should not be reachable from the public internet. For Cadence, confirm equivalent authentication, authorization, TLS and payload protection controls with the project and in your own test environment before assuming parity. Whichever platform you choose, decide early who owns payload encryption keys, since workflow data passes through the codec path.

Questions teams ask before choosing Temporal or Cadence

Does Temporal Cloud cost more to run than self-hosting Temporal?

It depends on what you count, and the answer changes with your action volume. Temporal Cloud pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to Temporal's pricing page. Self-hosting carries no per-action fee from the vendor, but you pay for compute, the persistence database, a visibility store such as Elasticsearch or OpenSearch once executions grow, backups, monitoring, upgrades and the engineers on call. Action counts, retained history and the availability tier you need drive the Cloud bill up. Ask Temporal for a quote built on your expected action volumes, and have your platform team cost the self-hosted cluster including staff time. Compare both totals over the same period.

What does running a self-hosted Temporal cluster need from our team?

A self-hosted Temporal Service runs Frontend, History, Matching and Worker services alongside persistence and visibility stores, so it needs people who can operate that stack. Deployment options include Docker Compose, Go binaries, Helm charts on Kubernetes, or a custom Go build that imports the server package. Helm chart versions below 0.73.1 do not work with server images 1.30 and later. Upgrade one minor version at a time, moving to the latest patch first, and run schema upgrades before server upgrades when the release notes call for it. Security also falls to your team: without a configured Authorizer, the default noopAuthorizer allows every API request, so you must set up mTLS, a ClaimMapper, an Authorizer and OIDC for the Web UI.

How long does a migration from Cadence to Temporal take?

No duration is supplied for this migration, so treat any timeline you hear with caution and ask for one in writing. The main drivers are the number of workflow types, how many executions are still running when you cut over, and whether they must finish on the old cluster or be moved. Your SDK language matters, because workers written against Cadence's Go or Java SDKs need to be reviewed against the Temporal SDK for the same language. Your persistence and visibility stack adds work if you change databases or search backends. Confirm with Temporal and the Cadence project how they recommend handling in-flight work, then ask any implementation partner for a written scope that lists workflow types, environments and cutover steps before agreeing a timeline.

Does Cadence have a managed service like Temporal Cloud?

The supplied facts describe Cadence as an open-source project under CNCF governance, with an official Helm chart and a Google Kubernetes Engine codelab, but they do not name a managed Cadence offering. Confirm with the Cadence project and the CNCF whether a hosted service exists before you plan around one. Temporal is different: Temporal Technologies sells Temporal Cloud, which carries a 99.9% SLA, or 99.99% with high availability, and SAML SSO, according to Temporal's pricing page. If you choose Cadence, plan to run the backend services, your database (Cassandra, MySQL or PostgreSQL), and any optional Kafka and Elasticsearch components yourself, unless a provider confirms in writing that it operates them for you.

Should a Go or Java team choose Temporal or Cadence?

Both platforms offer official Go and Java SDKs, so a Go or Java team can build on either without changing languages. The differences appear elsewhere. Temporal also documents Go, Java, TypeScript and Python for workflow code, which matters if other teams write services in those languages. Cadence's Python and Ruby SDKs are unofficial community projects, so check their maturity before relying on them. Choose Temporal if you want a single vendor-backed product with a managed option and a wide SDK set. Choose Cadence if CNCF open governance and its named production users weigh heavily in your decision, and you can run the backend yourself. Test both SDKs with one real workflow from your codebase before you decide.

Do the MIT and Apache-2.0 licenses limit commercial use?

Temporal Server is MIT licensed and the Cadence repository is Apache-2.0 licensed, and both are permissive licenses that allow commercial use, modification and redistribution, subject to their license terms. The practical differences lie in who stewards the project and how you can buy support. Temporal Technologies maintains Temporal and sells Temporal Cloud as a managed service. Cadence is a CNCF project under open governance and has no vendor-operated managed option in the supplied facts. Have your legal or procurement team read the license files in the repositories and any commercial terms before you sign, since this summary does not replace legal review.

Can DeployOpen run Temporal or Cadence for our team?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. That work can cover a self-hosted Temporal or Cadence deployment, including the persistence choice, Kubernetes or other deployment method, and security configuration. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen does not issue audit reports or certifications, so independent assessors remain responsible for any compliance attestation. Start with the Temporal self-hosted deployment guide to see what your team would own.

How DeployOpen helps choose, implement or migrate a durable execution engine

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Temporal vs Cadence decision, we start with the workloads, the languages your teams write in and the persistence and visibility stores your operations group can run, then build and hand over the option you choose.

How we scope

We agree a written scope covering which engine fits your workflow types, languages and team skills.
Scope documents the persistence and visibility stores to be tested, such as PostgreSQL, MySQL or Cassandra.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen engine in your cloud accounts, data centers or air-gapped network.
We configure mTLS, namespace authorization and SSO settings so no API is left open by default.
We test failure recovery, worker restarts and upgrade paths against your own workflow code.

How we hand over

We deliver architecture notes, runbooks for upgrades, backups and restores, and access configuration.
We document the SDK conventions, versioning rules and visibility queries your developers will use.
We walk your platform and security teams through the running system and the evidence it produces.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover minor and patch upgrades, schema changes and review of new release notes.
Ask for the support scope, response arrangements and upgrade process in writing before you commit.

Temporal vs Cadence