Temporal Reviews

The main purposes for using Temporal are automation flows, especially financial automations and supply chain automations. Our company name is SR, we are a digital-first CPG brand making company, managing over 70 brands, and managing the supply chain in terms of POs, transfer orders, and moving stock between 3PL to Amazon and vice versa involves a workflow process that could include manual or automated steps, and for everything, we use Temporal.

We are just a customer; we directly use it for our internal use cases, building software for our company, and we are not a reseller or any of those modes.

Our workflows are pretty straightforward, not involving multi-step or multi-stage workflows. It's more about making sure it is an automated workflow, not big complex workflows. Therefore, the basic retry mechanisms are solving our needs, and we haven't explored the advanced capabilities yet, as our problems are already resolved.

In terms of scalability, it is the best feature. I did use Camunda in the past for almost three years, and resource constraints-wise, Temporal is much more prudent in doing the work. While Camunda comes with an exceptional UI and more forms, for our use case, pace is more important than actually the UI. Hence, I would say Temporal is working in the right way.

The deployment process is quite straightforward as it provides both Kubernetes and Docker Compose versions, allowing us to run it in ECS containers, and I find it simple for both Camunda and Temporal.

The only area for improvement in Temporal is the UI. I know it is a non-UI first product, but comparing Camunda versus Temporal UI, there is a difference. Moreover, n8n, being a no-code platform, is easier for business people when writing workflows. Hence, we maintain two systems today: n8n for no-code solutions where business automations can be managed, and Temporal for mission-critical systems which cannot fail.

We have been using the solution for roughly about eight months now, not one year.

I do not see performance issues or latency problems with Temporal; the stability largely depends on how we write the code rather than the tool itself. Both Camunda and Temporal are stable as long as we adhere to proper design patterns.

I am tight on schedule today. We can discuss Camunda sometime later, but I can only provide insights on Camunda 7, as I chose Temporal over Camunda 7 for production use.

We haven't engaged any Temporal experts; we've learned everything from their documentation, which I find helpful and clear with examples.

The ROI is apparent in terms of business case automation; previously, a bunch of people filled in data in NetSuite or managed stocks between warehouses and Amazon, but now everything is automated, saving time. We have streamlined processes and saved roughly 300 to 400k in chargebacks, considering our revenue is around 0.5 billion a year.

In terms of pricing, Camunda is indeed costlier than Temporal. The cloud deployment costs differ, and while Camunda 7 can be cheaper due to its integrated setup, comparing latest versions between Temporal versus Camunda 8 is not straightforward. Temporal is faster and cheaper regarding our use cases.

My overall experience with Temporal is rated between 8 to 9, mainly due to a learning curve that only senior developers can navigate effectively, which makes it a bit challenging for junior developers.

We don't have any instances of on-premise, so I cannot comment on that because we are a first company, with all services deployed on cloud infrastructure.

Most of the integration is through RPC or APIs, ensuring all our systems are in cohesion.

We do state persistence to a Postgres instance, and we have modified it to our use case with better indexing. And for fault tolerance, we built a queue and an alerting mechanism that notifies us if any workflows fail after specific failure points so we can act upon it.

On a scale of 1-10, I rate Temporal an 8.

I'm part of MoCS's platform engineering team. We initially searched for a workflow orchestration engine and discovered Temporal, which met all our development needs. We implemented Temporal in-house and built a self-service platform called Dash for developers, which allows them to use Temporal as needed.

I’m part of the API management team, focusing on deploying API proxies onto gateways. We use Temporal to orchestrate these proxies and manage the API management lifecycle, including deployment processes.

In addition to API management, our entire platform engineering team utilizes Temporal to orchestrate infrastructure tasks such as deployment, deletion, and management. On the business side, Temporal is also used to manage shipment bookings and invoicing processes.

Temporal focus on developers rather than business users. In contrast to older workflow orchestration engines like Camunda, which are more business-oriented and strongly emphasize UI and workflow authoring, Temporal is geared toward developers. It provides extensive capabilities for building complex workflows.

A standout feature of Temporal is its handling of long-running workflows, a significant advantage over many other solutions. Temporal excels in managing distributed transactions and application state durability, especially in microservice environments where transactions might fail due to network issues.

Temporal simplifies these challenges by managing retries, fail-safes, and circuit breakers. As a result, developers don't need to implement these features manually; Temporal handles them implicitly, though it also allows for tuning based on specific needs.

Developers often mention the desire for a more intuitive visualization of workflow states. While Temporal has matured significantly, its current workflow state visualization can be challenging to interpret. The tooling required for visualization, such as integrating with platforms like Grafana, involves extensive instrumentation that developers must handle. Improvements in this area would be beneficial. Additionally, the methods and documentation could be enhanced, as Temporal’s SDK can be costly and has a steep learning curve. Better documentation would be crucial to help developers navigate these challenges.

I have been using Temporal for more than two and a half years.

 Our entire bot uses Temporal quite heavily. 

Scalability depends on the infrastructure. Temporal is highly scalable because it is divided into history service, HD servers, and others. The infrastructure is distributed, and Cassandra is used to manage the state, which is also highly scalable. Uber has designed the infrastructure to be scalable, but building it in-house requires significant DevOps skills. CapEx is substantial for orchestrating and managing the infrastructure; scaling it can be challenging. A dedicated team is needed to manage and scale the infrastructure.

We do have access to the community channels where the community is quite helpful, and many Temporal engineers respond to issues. The platform is great. Maxim himself responds to a lot of issues, even though he is the CEO.

When segregating services, transfer failures, network interruptions, and service downtimes occur. All these things need to be handled. Developers handle it by building SDKs or using other tooling and a cache. A developer has to consider many different products and tools to solve all these problems.

To complete a booking, you must code it to accept the booking and process the payment. But you must also worry about what happens if your payment system is down. 

These things require additional tools and platforms for a developer to achieve these goals. With Temporal, all these issues can be addressed with the system itself, eliminating the need for additional infrastructure or separate mechanisms to handle them.

We use the open-source version of Temporal. 

I highly recommend Temporal for building critical systems that involve distributed transactions. It's an excellent choice for such scenarios.

The cloud option is a good fit if you want to minimize CapEx and don't have many long-running workloads or operations running continuously. Building and managing it in-house might be more cost-effective if you have substantial use cases with many teams or numerous workloads that need to run persistently.

Overall, I rate the solution an eight-point five out of ten.

My friend and I are building an online software as a service platform that uses Temporal extensively. One of my use cases is integrating Keycloak, a single sign-on solution that sends events for bootstrapping organizations and users. I've created an open-source plugin or module that anyone can download and use in their projects, published on GitHub. Another use case is bootstrapping cloud-native solutions. You can write code to initialize the whole solution, defining all steps needed in a serialized fashion. Temporal runs through all sequences, workflows, and activities that need to be processed.

What I like best about Temporal is its durable execution, which means you don't need to write many boilerplate code for critical pieces, especially for retries. It also has great observability and a nice dashboard to see issues without digging into logs. The interface for viewing activities is excellent, with good tracing that shows how long activities took and what ran, making it almost perfect for debugging.

While the tool can be a bit daunting initially, especially if you're not used to async programming models, it's generally a pleasure. There's always room for improvement, though. I've noticed some limitations with the .NET SDK regarding dynamic workflows, but this might have been improved in recent versions. Overall, I think Temporal could be more open about implementing features in a more—.NET-friendly way, especially in how you add workers and clients.

I have been using the product since November last year. 

Stability-wise, I'd rate the solution an eight out of ten.

I've contacted the support team through the Slack channel for development questions. Their response time is usually within an hour, but it can depend on the time difference as they're based in Washington.

Positive

Setting up Temporal is easy for development —you just run one command. However, depending on your requirements, it can be more challenging for test or development environments. The solution isn't a one-size-fits-all solution. For smaller-scale deployments, it's not too hard. You can use Helm charts for Kubernetes, which only needs a Postgres database. My friend deployed it without much trouble. For larger-scale operations, with millions of operations, you need to use Cassandra DB with Elasticsearch, which requires a lot of resources.

The tool is open source under the MIT license, so there are no hidden fees. You can freely use everything on their GitHub and Docker images.

Overall, I'd rate Temporal a nine out of ten. I would recommend it, especially for bigger organizations or those with more async models of doing things. It might not be suitable for small companies.

I use it to handle messages from the WhatsApp API. There is a product in my company that uses that API, and Temporal helps us debug and handle retries about the messages we receive, persisting the delivery of the message to the final client.

I like the inner retry system that it has, as a developer. The availability it provides to our products is great. When a micro service crash, Temporal handles the retry by itself. It helps a lot in our company and is by far the best thing Temporal has created.

I think people need to have some experience, at least with event-driven design. When someone tries to understand the signals, queries, and updates, it becomes a little challenging if they haven’t worked with webhooks or event sockets. But if someone already knows about event-driven designs, it’s pretty simple.

Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases.

The scalability is great, but could be better.

We needed to change Temporal's database from Postgres to Cassandra to handle it more cheaply for our infrastructure. We do not use Temporal Cloud; we use Temporal Open Source. Cassandra DB was the best choice because it was cheaper. The problem with Postgres was the only problem we faced. But besides that, it has been great since the start.

I have been using it since January 2023.  I’ve been using it every day since.

One time, we had a problem with the database. Our PostgreSQL queries from Temporal reached the maximum connections at the same time, and then Temporal’s cluster crashed. It was the only time, and it was a problem with our infrastructure. When we changed it to Cassandra, it never happened again.

I would rate the stability a nine out of ten.

It’s working fine in my current company. We have about three million workflows running at the same time. Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases. In general, I think it’s great but could be better.  

I would rate the scalability an eight out of ten.

I haven’t faced another challenge besides scalability. We drive around five million events in a small day.

I never needed the support, but sometimes I use the community to speak with them.

Positive

The initial setup is easy. I didn’t have any problems deploying it in production or on the devs’ local host. It was pretty great for the devs in general. I think it’s pretty great.

Our project was designed in Temporal. It started with Temporal, so we didn’t have any problems before.

We handle on-premises, and we participate in Temporal community.

There’s a return on investment and it’s worth the money.

Temporal OSS is expensive in infrastructure, but it brings back the reliability that companies need.

I would recommend it to other people. Try Temporal Cloud because on-premise is kind of expensive.

Overall, I would rate it a nine out of ten.

We have multiple products and wanted to use Temporal because different business logic was better suited to different programming languages, such as Java and Python. We needed a unified solution to handle this diversity. Netflix, one of our clients, introduced us to Temporal.

We set up an on-premise Temporal server, with Temporal handling the initial setup in our Kubernetes cluster. Another team implemented additional security measures on top of Temporal to enhance security. We developed our authentication system and library to integrate with multiple role-based access control systems.

We use Temporal primarily for orchestration. We deploy products across AWS Cloud, Azure, and on-premise data centers. Temporal helps us centralize the orchestration process. We use the Temporal SDK to implement our workflows and workers in our Kubernetes cluster. Based on user requests from a centralized portal, we trigger workflows, which drive multiple tasks sequentially or concurrently to deliver the desired outcomes.

Temporal has had a strong positive impact on our organization by significantly improving the reliability and observability of our distributed workflows. By providing durable execution, built-in retries, and state persistence, Temporal has reduced failures caused by transient issues and eliminated the need for complex custom retry and recovery logic.

From a developer productivity standpoint, it has simplified orchestration of long-running and asynchronous processes, allowing teams to focus on business logic rather than failure handling and state management. Debugging and monitoring have also improved due to Temporal’s rich workflow visibility, making it easier to trace execution paths and quickly identify issues.

Overall, Temporal has helped us build more resilient systems, reduce operational overhead, and deliver features faster with greater confidence in production stability.

Temporal solved a major problem for us. Implementing a saga pattern or a workflow management system traditionally requires handling many aspects beyond business logic. These include retry mechanisms, rollback mechanisms, logging, monitoring execution status, and features for pausing or resuming workflow execution. Temporal provides all these features by default, allowing us to focus solely on our business logic while Temporal manages the rest.

The network should consider adding a basic authentication system to Temporal, such as JWT token-based authentication. Temporal doesn’t include these features by default, and while Temporal Cloud might offer them, on-premise users have to build their security systems. This is an area where there is room for improvement.

Temporal terminology can be confusing for new users. A more user-friendly approach or improved documentation could help ease the learning curve. The current documentation often requires users to piece together information from various sources, including existing implementations from other organizations or direct developer support. The documentation needs a significant update. Not all necessary information is available online, and community support is limited. For instance, our security team implemented certain features a year ago, but it included relevant information in their documentation. Improved documentation and better community support would greatly benefit users working with Temporal.

I have been using Temporal for the last one and a half years.

While Temporal is generally stable, improvements could be made in some areas. Temporal UI provides information on execution status; it only shows the latest state and not the history of previous attempts or failures. This limits our ability to diagnose issues without setting up a separate logging system in tools like Splunk or Elasticsearch.

The traceback provided by Temporal isn’t always helpful when working with core areas such as interceptors. For instance, verifying if tokens are correctly attached to headers and linked with requests is difficult.

Another challenge is with SDKs. Temporal uses different approaches depending on the language: for Go and Java, it provides native SDKs, while for Python and TypeScript, it uses a Rust core with wrappers. This division makes it difficult to trace issues in the Rust core from Python or TypeScript, creating a barrier to debugging and development.

I rate the solution’s stability a seven out of ten.

From a scalability perspective, Temporal excels. It allows us to spawn multiple workers and handles task distribution across them efficiently. We don’t need to worry much about load balancing. We build and launch as many containers as needed, pointing to the same Temporal server. Its server is a load balancer and a queue system, making it highly effective for scalable applications.

It would be beneficial if Temporal could simplify scalability by allowing workers to spawn multiple processes within a single container based on a specified number rather than deploying multiple containers. This approach would streamline scalability and reduce the need for additional management from the Jenkins side.

We have around ten to twelve services running on the top of Temporal.

I rate the solution’s scalability an eight out of ten.

We did not find any dedicated support. We had to either raise concerns in their forum or connect to the Slack channel of Temporal and raise concerns in the appropriate channel, such as the Python SDK channel, for Python-related issues. 

They operate in US time zones, and since I am in the Indian time zone, I have to wait until they are online to receive assistance. The support is text-based only, and there is often a delay.

Positive

Suppose you have multiple technologies across your portfolio and want to implement business logic. In that case, it’s better to use technologies like Temporal instead of converting all the business logic to a single language. If you’re starting from scratch and the business logic is simple without complex scenarios, using Temporal from the beginning might not make sense because it can be complex and requires heavy infrastructure, which increases costs. Temporal may not be recommended for small-scale projects, but it could be a good fit for larger scales where you’ve already implemented many things in different languages.

Overall, I rate the solution an eight out of ten.

In general, we use Temporal for workflow management. Some of the information is private because I work for a private company.

Temporal allows retryability for different workflows whenever they fail. It helps us to retry workflows without worrying about idempotence and ensures things get done.

Temporal allows retryability for different workflows whenever they fail. It helps ensure idempotence and that things get done.

Retro compatibility needs improvement. Sometimes, when we make new changes to a workflow, it fails if it is not configured properly due to compatibility issues. I wish this could be improved so developers wouldn't have to worry about compatibility.

I have been using Temporal for about a year.

In terms of stability, I would rate it a nine as long as the developer doesn't make mistakes.

It is pretty good in terms of scalability. We haven't had any issues as long as it is in the cloud.

I have not contacted their support team directly, but when I read through their blog posts and see the responses, they seem to be doing pretty well.

Positive

I used RabbitMQ in my personal projects before using Temporal.

The initial setup is of medium complexity.

Temporal is a pretty good product for workflow management.

We use Temporal for several purposes. One is for scheduling purposes, where we have workflows that must run at regular intervals or over long durations. Another involves triggering specific events, like in a video processing pipeline, where processing begins as soon as a video becomes available. We also use it for ETL purposes, where once data is available in the data store or warehouse, Temporal triggers the necessary analytics processing. Different teams also define and use the tool based on their specific needs.

From my experience with the tool, I think its best feature is fault tolerance. If an issue occurs, it can be retried from the last successfully processed step without reprocessing the same message. This gives us confidence that completed events won't be retried unnecessarily, even in case of failure. Additionally, it offers a great dashboard and monitoring features, allowing us to see if and where any failures occur, and we can easily retry or replay events to identify issues. Another strong point is that Temporal stores all events in a database, handling everything independently. This feature makes it easier to debug and track logs as needed.

The tool is easy for a beginner to learn. The documentation covers activities, workflows, workers, servers, and more. While more examples could be beneficial, the existing resources are good enough to help you get started. There are also YouTube videos available that can provide additional context. The Slack community for Temporal is very active and helpful, similar to Stack Overflow, where you can find answers to a wide range of questions from basic to advanced levels. If you have a unique question, the community is responsive and provides knowledgeable support.

One area where I think Temporal could improve is its dashboard, particularly in event tracking. Currently, the dashboard doesn't show a time-based view of events, meaning it doesn't display when an event started or went through the retry process. If this feature could be added in a future release, it would significantly enhance monitoring capabilities. Other than that, Temporal's overall performance is quite impressive, and we're confident we can migrate to the Temporal workflow.

I have been using the product for two years. 

When we started the POC, my team was the only one using workflow management, with around ten people. However, it eventually expanded to the entire company, so the whole engineering team is currently using it. I can't say the exact number of people because it’s a company-wide adoption.

I have talked to Temporal's support team before. They have a Slack channel and community, which I joined. We faced an issue with the scheduling of EventBuild in some time zones. I asked a question there, and they quickly responded to my query and solved my problem. The support team is very active and generally provides the best solutions possible. The community is great and very helpful.

Before the tool, we used Airflow, but it didn't support complex business logic and only worked with Python. We explored options like Cadence and other workflow management or event processing systems. However, after doing a POC, we found that it offered multiple SDKs, allowed us to write complex business logic, and provided a good monitoring dashboard. So, we decided to switch to Temporal and finalized it as our workflow management solution.

Deployment is easy, especially if you're familiar with Kubernetes. We used Helm for the deployment, and it was straightforward to set up the web service, UI service, front end, and everything else. It didn't take much time, and the documentation was helpful, though it could be improved. The documentation sometimes only covers the basics, which might not be sufficient for someone new to Kubernetes. However, for those with experience, the deployment process is smooth. I also created a document to guide others through the deployment process.

The tool's cost depends on how you implement it. If you're running it in-house, using your own infrastructure like Kubernetes, and managing your own database (e.g., Cassandra), the cost isn't different from what you might be paying for other workflow management solutions. However, you may save some costs by consolidating multiple jobs into a single workflow, which can reduce the number of workloads and resources you need.

On the other hand, cloud hosting might be more expensive. We haven't tried cloud hosting, so I can't provide specific details on that, but it's something to consider if you're looking at cloud-based options.

If you're considering using the tool for the first time, my advice would depend on your specific use cases. If your needs are simple, with no long-running processes, and retrying the same event without issues is acceptable, you might be fine using alternatives. However, if your business logic is complex, especially if you need to ensure that once an event like a transaction is processed, it should not be retried, then Temporal would be a better choice.

Just note that while it's great for these purposes, adding something like a DAG implementation would enhance its usability even more. But overall, Temporal is one of the best options for complex and long-running processes.

Overall, I would rate it around seven to eight out of ten. It solves many problems, like availability, consistency, retry logic, and offers a good dashboard. However, the reason for not rating it higher is due to the documentation and event graph, which could use some improvement. While the documentation is great, it could be more detailed, with more examples, and the server deployment can be tricky for those unfamiliar with it. Additionally, a more advanced monitoring tool, such as a visual graph showing the workflow's progress and where any failures occurred, would be a valuable enhancement.

We have some long-running workflows, like callbacks, that we get after a day or two. We use Temporal for that.

It enables us to use it for something like a continuous process that needs a callback or has multiple steps to be followed. 

It could also be something like having some set of activities that need to be created for a particular task but some other sets for different tasks. It's useful in those situations.

There are some issues that we face with the versions of Temporal and the databases that we use for Temporal. That's the pain point for us. 

We have been using Astra DB for Temporal, and that has been creating issues. Versions lower than, I guess, v14 point something has some issues. We get some errors in the lower versions. So, sometimes, the workflow gets terminated because of that.

It's been around one and a half years.

Currently, I have not faced any major issues with stability. 

We face issues regarding the databases themselves and nothing apart from those.

60% of our employees use it. I prefer them to use Temporal unless it's for long-running workflows or something where you need to generalize a solution, then it's very useful. 

The other issue is that Temporal's debugging is a bit complex. I guess that's the other issue. I guess it's mostly sorted in the newer versions.

Like earlier, it does not support Elasticsearch. Actually, earlier, it wasn't supported. So, it supports it in the newer version.

I have met some core teams of Temporal. They have been to India and Bangalore, and there was an event for the same. I have been there.

From there, I realized that this issue that I get is due to the versions and all.

Positive

The initial setup is easy.  

The pricing is worth it. The price that they've set is, I guess, worth it.

It's completely up to your requirements. If those requirements meet the expectations of Temporal, I would suggest you go with Temporal rather than any other system. Because in Temporal, you can actually track the activities that have been performed, and it has a proper UI. So it would be very easy for you to debug things and the errors that you have rather than check all the logs.

It is easy for a beginner to learn to use Temporal for the first time. Overall, I would rate it a nine out of ten.

We [my company] use  it to run a large workload. We have a set of security scans we want to perform, and we distribute them over a full day, that’s over 24 hours. We use it to orchestrate all the steps necessary to perform those tests.

It’s essentially an orchestrator. So, we get all those properties we want from an orchestrator. Particularly, we like the fact that the whole process is durable, which is very useful to us. The fact that you can split it up into multiple smaller steps, called activities, and store state at every single activity is something we have made a lot of use of. For example, this allows us, in case of any failures down the road, to stop the process midway and resume it later. That’s another feature that’s been really useful.

We like the fact that it integrates very well with the programming language. It’s not completely transparent; you know you’re using Temporal because you have to import the SDK into the programming language itself. But it’s done in such a way that it’s really easy to write and fits well within the language. Personally, I like that the main abstraction, workflows, allows you to follow domain-driven designs super easily. In your workflow, you can essentially speak your business language and not have to worry too much about Temporal because it’s abstracted away so nicely.

One last feature that’s super useful is that retry policies are built into the Temporal system. For example, if one of your activities fails for multiple reasons, you can configure how you want to handle your failure cases in the activity itself with a retry policy. You can say, “Okay, I want to retry this later,” and configure the cadence. This step is really configurable, it’s built into the system, and it’s something we have made a lot of use of. So, that’s pretty much a big picture summary.

The actual user interface is still in its early stages. It’s very basic. Users don’t really have a complex permission model yet. Users don’t really have ways to automate things like, for example, provisioning the Temporal namespace via Terraform. Users can’t do that yet. Users still have to do it manually.

Another thing I remember is the certificate rotation. Users can’t configure that to be done automatically. Users have to do it manually in each of the Temporal namespaces, which is actually super annoying for us. We’ve been talking with them about whether or not they were going to add a feature that would support that, and they said that it’s in the backlog, and they’re still working on it, but they don’t really have a timeline for it yet.

So, the operations on the interface are still in very early stages. Users can’t really do that many things when it comes to administration. The essential things users can do, but the more convenient things, some of them are lacking. So that’s a downside.

When you run your activities, it would be nice if you would not only see the latest error you get from an activity. When you do an activity, there are retries. Retries happen for various reasons, which means you can execute the same activity multiple times and get different errors. Now Temporal only shows the latest one. It would be nice if it showed all the errors. I’ve been reading a bit about it, and as far as I understand, it’s a limitation of how the system is built. But from what I understood from my colleagues, they talked to Temporal, and they said that there is possibly going to be a way to do that. I’m not sure whether that’s true or not, but it would be really nice. So that’s something that came to mind.

Another aspect of it that I don’t like is that Temporal Cloud is not friendly for smaller users. I wanted to include Temporal in some of my projects, and Temporal Cloud would have been a nice addition because managing the self-hosted cluster, I did not find easy. There’s a lot of setup in doing that. It would have been nice for me to use Temporal Cloud, but the pricing model doesn’t really allow for that. If I remember correctly, there’s $200 customer support fee you have to pay for Temporal if you register for Temporal Cloud, which is obviously way out of my budget for a self-hosted user that just wants to run a few workloads. It would be nice if they made some changes to their pricing model so that not just companies have an incentive to use Temporal Cloud. Because, at the moment, there’s no way for me to do it without having to pay a lot of money.

I have been using it for last nine months now. 

We run quite a lot of volume, so the product is pretty good on that side. Mainly, your scalability will be in your infrastructure because Temporal doesn’t run any workloads. Temporal only stores your state. The processes that are actually running those workloads are your workers, and those are running on your infrastructure and are going to port a queue.

So, basically, if there are bottlenecks in your workload, if they need scaling, it’s a change you would do on your workers. Now, obviously, there’s the question of whether the Temporal cluster itself would scale because if you run a lot of things at the same time, then you’re going to have a lot of writes to the Temporal cluster and a lot of changes to their cloud databases. But we haven’t really had problems with that. They scaled pretty well according to our needs.

For the self-hosted cluster was much slower, but the cloud one has met our demands in terms of scalability.

It’s multiple users and multiple locations now. It’s quite a large volume in our case.

All tech support has the way we interact with them is via Slack. We have a Slack channel in which we talk with them. They’re pretty quick.

They were helpful. There’s nothing really to complain about there. They’ve always helped us whenever we asked them, and they regularly check in to see how we’re doing. If they see issues or weird traffic patterns on their side that they consider not necessarily best practices, they reach out to us. I’ve only had good times with tech support.

I’ve really nothing to complain about the technical support. I just go for it and I’ve only had good experiences with the tech support.

Positive

Some of my colleagues might have used Amazon Workflows, but I haven’t. From what I can gather, they’re fairly similar products, but Temporal turned out cheaper, which was one of the criteria they used to select it.  

There have definitely been some problems we’ve had with it. For us, it wasn’t just take it out of the box and it worked right away. We had to do a lot of configuration to get it working in the state we wanted. It was a lot of back and forth with Temporal.

First, we used the self-hosted version, so you can self-host it yourself. But that didn’t scale too well for us. But we migrated to the cloud at some point.

We mostly worked with it on the cloud, but it wasn’t all good right out of the box, even after we migrated to the cloud. We had certain issues, and some of those issues were because we didn’t know all the features it had to provide. Some of those issues, even Temporal, we didn’t know how to fix because we think they were due to the very large volume of work we were scheduling in a very short amount of time.

In our use case, because we do a lot of work with it every single day, we had to spend quite some time configuring it and getting it to work how we wanted. But that’s not necessarily the case for other user flows that use Temporal and have a very different traffic pattern. Those were much easier to get working well with minimal configuration.

I was not involved in the initial step. I was involved in subsequent steps, which did the transitioning between the self-hosted and the cloud setup, but the cloud setup was already there when I came. I took part in provisioning some new namespaces, but it was mostly ClickOps. From my perspective, getting started with Temporal Cloud was probably more work on the business and product side rather than on the engineering side. I think that on the engineering side, the amount of work you have to do to get your cloud account running is really minimal.

Three resources were involved in the migration process and the setup of the cloud environment.

From maintenance point of view, we have to maintain the workers. But from a maintenance point of view, it’s alright. It’s a SaaS solution, so Temporal do most of the hard work. One maintenance aspect is the certificate rotation. That’s really annoying to do. 

The maintenance for the self-hosted cluster is much more complicated and one of the reasons we’ve migrated. But, that’s also due to the fact that, being a security company, we have to respect strict security guidelines, which means that we have to modify some of the images that they provided because they didn’t respect those guidelines yet. For example, Temporal images aren’t FIPS compliant, and we have to be FIPS compliant.

For us, it ends up being quite costly. But it’s still probably more cost-effective for us to do it using Temporal. So, it’s a bit expensive, and it would be nice if the cost didn’t scale linearly because, at the moment, they have something like $25 per million actions, and then that keeps decreasing given the amount of actions you have, which is okay. But in the end, it’s still linear.

If you build a solution yourself, you will have a lot of maintenance costs, a lot of costs for the engineers involved in doing that. And, specialized resources. That’s the product they’re building, and they’re investing a lot of time with it. So you might not get away with something as reliable.

Now,  unless you need an orchestrator, unless you need durability, for example, if you’re a payment service provider, then you absolutely need that durability. But if you’re just an early startup doing some basic CRUD operations, so you’re at the very beginning, then you probably don’t need the durability. So you definitely have to take into account whether or not you actually need that durability when you decide on the solution.

If this business logic can fail and if that’s a use case we can tolerate, then you probably don’t have to go and purchase Temporal. But if you have a business operation that absolutely cannot fail, we absolutely cannot tolerate the failure; this operation has to run to completion, then you should definitely consider an orchestrator like Temporal.

I might be biased because I really like this technology. I’m not going to go for the ten because of the downsides but Temporal would be a strong eight out of ten, definitely nine. But if they consider improving the weaker points, I would definitely see this as one of the strongest stacks we have currently.

I’d recommend it, but be cautious before going for the tech just because it sounds nice. Users definitely have to lay out their use cases and figure out whether they need an orchestrator in the first place becauses it’s not a Swiss army knife. It’s not a tool that fits every use case. But for our use cases, for example, I definitely recommend it. It's a really good product.

We use the product in our environment to manage a complex data pipeline for our highly data-intensive virtual operating system. Our system processes continuous data flows from instruments worldwide that collect stratospheric weather data. This data undergoes multiple conversions through several layers to reach an L2 format. 

The platform has significantly improved our organization's handling of complex and long-running workflows. It has enhanced our distributed systems' resilience and fault tolerance, especially considering our extensive use of load balancers, API gateways, and complex server configurations. It ensures that if something goes wrong, it is handled in a way that minimizes harm.

The solution's most valuable features include its ability to simplify the management of complex workflows, improve system resilience and fault tolerance, and reduce the need for extensive boilerplate code. 

One area for the product improvement is the learning curve. It can be challenging for new users, particularly those unfamiliar with the concept of workflow as code or data-centric applications. The complexity of managing the pipeline introduces some operational overhead, which requires more communication and coordination within the team.

I have been using Temporal for approximately nine months.

The solution is highly stable, particularly in maintaining resilience and fault tolerance across distributed systems.

I have had positive experiences with Temporal's support, particularly through their Slack workspace, where original developers are highly responsive and engaged in user support. They typically respond within a minute and remain involved until the issue is resolved.

Previously, we used tools like Airflow and DAXTER. We switched to Temporal because it offers superior fault tolerance and robust techniques for handling complex workflows.

The setup complexity is context-dependent. For our proprietary system, we integrated Temporal, which required managing multiple integration points, such as Docker servers, endpoints, distributed databases, and configuration management systems like NGINX or Caddy. While the installation was straightforward, the testing process was more complex due to using workflows as daemon processes.

The implementation was done in-house. 

For those new to workflow orchestration tools, start with simpler tools like Airflow before transitioning to Temporal. 

Temporal is better suited for users with a solid concept understanding and a well-developed intuition for complex systems.

It was chosen for its robust techniques in handling such complex workflows. We operate it on-premises using dedicated servers, and our customized scripts manage it.

I rate it a ten out of ten.