The Quiet Defection From AWS
Temporal is not a household name outside engineering circles, but inside them, it has become a serious talking point. The open-source workflow orchestration platform, built by former Uber engineers who created Cadence, has been gaining ground with backend developers who are tired of the constraints that come with AWS Step Functions – Amazon’s managed workflow service that has dominated the space largely because of its proximity to the rest of the AWS ecosystem.
What’s driving the shift isn’t just feature comparisons. It’s a deeper frustration with how Step Functions forces developers to think. The service requires workflows to be defined as JSON-based state machines, a format that feels foreign to engineers who want to write code, not configure infrastructure. Temporal flips that model: workflows are written as regular code in languages like Go, Java, Python, and TypeScript. For teams already living inside their codebases, that difference is significant enough to change vendor decisions.
What Temporal Actually Offers
Temporal’s core idea is that long-running business processes – think order fulfillment, user onboarding, payment retries, data pipelines – should be expressed as durable code rather than declarative state machines. When a Temporal workflow pauses for hours or days waiting on an external event, the execution state is automatically persisted. If a server crashes mid-workflow, execution resumes exactly where it stopped. Developers do not write checkpointing logic. They do not manage retry state. The platform handles it.
Step Functions does offer similar durability guarantees, but the implementation path is different. With Step Functions, every branch, retry, catch, and parallel execution is expressed in Amazon States Language, a JSON specification that grows unwieldy fast. Engineering teams maintaining complex workflows often end up with state machine definitions that are hundreds of lines of configuration, difficult to test locally, and nearly impossible to reason about without specialized tooling. Temporal workflows live in the same repository as application code, use the same testing frameworks, and run locally without any cloud dependency.
The ability to run locally is not a minor convenience. It changes how teams debug, how they onboard new engineers, and how they structure integration tests. A Step Functions workflow requires either deploying to AWS or running a local emulator that doesn’t always behave identically to the production service. With Temporal, the server itself is open source and runs in Docker. That parity between local and production environments has become a recurring theme in why engineering teams report switching.
The AWS Lock-In Calculation
Step Functions benefits from being inside the AWS tent. Organizations already running on Lambda, S3, DynamoDB, and EventBridge can wire Step Functions into those services with minimal friction. The IAM permissions model, the CloudWatch logging, the native service integrations – they all work because Amazon built them to work together. For teams deeply embedded in AWS, that integration story is genuinely useful, and abandoning Step Functions means writing more glue code to connect workflow execution to cloud resources.
But that convenience also creates dependency. Workflows defined in Amazon States Language cannot run anywhere other than AWS. There is no open-source runtime, no self-hosted option, no path to portability. As organizations think more carefully about multi-cloud strategies and vendor concentration risk, that lock-in carries real weight in architectural decisions. Temporal, whether self-hosted or consumed through Temporal Cloud, offers a path that does not bind the workflow engine to a single cloud provider.
Where Temporal Is Winning and Where It Isn’t
Temporal’s strongest adoption appears concentrated in companies building complex, stateful backend systems where workflow correctness is non-negotiable. Fintech companies running payment processing retries, healthtech platforms managing patient intake pipelines, and e-commerce businesses coordinating multi-step order fulfillment have all found Temporal’s durability model well-suited to their needs. These are environments where a missed retry or a lost state transition isn’t a minor bug – it’s a compliance issue or a revenue loss event.
Step Functions still holds a clear advantage in simpler scenarios, particularly where teams want to orchestrate AWS-native services without writing application code at all. Triggering a Lambda function, calling an ECS task, sending an SQS message, and waiting for a callback – these workflows are genuinely straightforward to express in Step Functions, and the visual workflow designer in the AWS console gives non-engineers a way to understand what the system is doing. For organizations with mixed technical audiences, that visual layer matters.
Temporal Cloud, the managed hosting service launched to reduce the operational burden of self-hosting, has become the primary commercial vehicle for the company. Self-hosting Temporal requires running and maintaining its own server infrastructure – Cassandra or PostgreSQL as the persistence backend, the Temporal server itself, and workers that execute workflow code. That’s not trivial. Temporal Cloud abstracts all of it, but the pricing model, which scales with workflow executions and storage, can grow quickly for high-volume applications. Teams evaluating Temporal for production have to run the numbers carefully against what they’d pay for Step Functions state transitions.
The developer experience advantage that Temporal holds is measurable in onboarding speed and code maintainability, but it doesn’t eliminate infrastructure cost discussions. A startup with modest workflow volume and an all-AWS stack may find Step Functions perfectly adequate. A team running hundreds of thousands of long-running workflows, maintaining them across multiple engineers, and deploying across different environments will likely find Temporal’s code-first model worth the operational overhead. The decision is less about which platform is better in the abstract and more about which tradeoffs a specific engineering team can absorb – and right now, a growing number of teams are deciding that JSON state machines are a tradeoff they no longer want to make.
