Clouded Judgement 8.22.25 - Workflows Are the New Databases

Every week I’ll provide updates on the latest trends in cloud software companies. Follow along to stay up to date!

Workflows Are the New Databases

Every major platform shift creates a new layer of infrastructure that quietly becomes indispensable. There are certainly many new layers of infrastructure being built out in this AI wave! But I want to focus on one for this post - workflow engines.

In the SaaS buildout, relational databases were the key layer that became indispensable. You couldn’t build Salesforce or Workday without a durable, consistent place to store state. Databases were the invisible foundation, something most users never thought about but were absolutely critical to making the applications work. They were the backbone of the “system of record” apps.

AI apps are now going through their own maturation phase, and key underpinnings of their infra is starting to emerge. The core challenge of AI agents (maybe the broader category that all AI Apps will turn in to), isn’t just model performance, it’s execution. Models are inherently probabilistic and stateless. They generate outputs, but those outputs often need to be chained together, retried, orchestrated, or connected to other systems. In other words: they need durable workflows. By durable workflows, I mean processes that can survive failures, pauses, and retries while keeping track of exactly where they left off. It’s the execution layer that makes sure your AI app doesn’t just run once, but that it keeps running reliably until the job is done.

Think about an AI agent that does sales outreach. It has to (1) pull data from the CRM, (2) enrich it with research and other 3rd party data, (3) generate an email, (4) respect per-user rate limits, (5) wait for a reply, and (6) escalate to a human if things go sideways. All while making sure the end to end process completes, or ends in a “finished or failed” state. And also, when an AI Agent vendor has thousands of agents running for their end customers, how do you avoid the “noisy neighbor” problem of one customer draining all the resources? All of these are real problems, and they’re new problems! It can’t be solved with a single API call, it’s a distributed workflow that needs persistence, retries, concurrency control, and observability. Or take a customer support bot that needs to pull records from five backend systems, resolve an issue, escalate if it fails, and loop back if the customer reopens the ticket. These are not stateless calls. They’re living, breathing processes that need an execution layer to survive failures and handoffs.

Right now, most teams are cobbling this together with queues, cron jobs, state machines, databases and a lot of glue code. It works at small scale but gets brittle quickly. You can feel the “rebuilding the database” moment here. Just as no one wants to roll their own database anymore, no one will want to build their own durable execution engine. This will harden into its own category of infrastructure.

The parallels to databases are striking:

• Databases stored state. Workflow engines store progress.

• Databases ensured durability. Workflow engines ensure execution durability.

• Databases standardized access. Workflow engines will standardize orchestration.

And just as relational databases grew from a “developer tool” into a massive market that underpinned SaaS, durable execution platforms will become the invisible backbone of AI-native apps. Every serious agent or multi-step workflow will sit on top of one.

There’s a bigger point here too: the history of software infrastructure is a history of abstraction. Developers used to write their own auth, their own job schedulers, their own billing. Over time, these hardened into categories and companies - Auth0, Stripe, Twilio. Durable execution feels like it’s on that same trajectory, except instead of being a nice-to-have module, it’s existential. Without it, your AI product can’t be reliable. And reliability is the difference between a flashy demo and a business people trust. And THIS is (in my opinion) very key for the next phase of AI Agents (ie AI applications). We need infrastructure to help take these ai apps from prototype to production. From a small A/B test rolled out to 1% of users to a full 100% role out. When I look at the vibe coding apps (Replit, Loveable, Bolt, etc), I think what could really take them to the next level is by offering their users durable infrastructure on the backend to help take vibe coded flimsy apps to durable production apps.

We’re still in the early innings here. Inngest, Temporal, Trigger and a handful of others are circling the space, each with different tradeoffs. Some lean enterprise-heavy, others focus on serverless and developer experience. But the need is undeniable!

In 5 years, I think we’ll talk about workflow engines the way we talk about relational databases today: not sexy, not visible to end-users, but utterly indispensable. The hidden layer that makes everything else possible.

This broader theme is one I’m thinking more and more about these days. If you’re building a company creating a new form of indispensable infra for the AI Agents world, I’d love to speak with you!

Post-published edit: I didn’t mean to suggest workflow engines will replace databases in the AI world. Databases are still foundational and always will be. The point was that databases existed long before SaaS, but SaaS made them exponentially more important. Workflow engines have also been around for a long time, and I believe AI agents will play the same role in accelerating their importance. Just like SaaS accelerated databases, AI will accelerate workflow engines.

Quarterly Reports Summary

Top 10 EV / NTM Revenue Multiples

Top 10 Weekly Share Price Movement

Update on Multiples

SaaS businesses are generally valued on a multiple of their revenue - in most cases the projected revenue for the next 12 months. Revenue multiples are a shorthand valuation framework. Given most software companies are not profitable, or not generating meaningful FCF, it’s the only metric to compare the entire industry against. Even a DCF is riddled with long term assumptions. The promise of SaaS is that growth in the early years leads to profits in the mature years. Multiples shown below are calculated by taking the Enterprise Value (market cap + debt - cash) / NTM revenue.

Overall Stats:

• Overall Median: 4.8x

• Top 5 Median: 28.1x

• 10Y: 4.3%

Bucketed by Growth. In the buckets below I consider high growth >25% projected NTM growth, mid growth 15%-25% and low growth <15%

• High Growth Median: 29.3x

• Mid Growth Median: 6.8x

• Low Growth Median: 3.8x

EV / NTM Rev / NTM Growth

The below chart shows the EV / NTM revenue multiple divided by NTM consensus growth expectations. So a company trading at 20x NTM revenue that is projected to grow 100% would be trading at 0.2x. The goal of this graph is to show how relatively cheap / expensive each stock is relative to its growth expectations.

EV / NTM FCF

The line chart shows the median of all companies with a FCF multiple >0x and <100x. I created this subset to show companies where FCF is a relevant valuation metric.

Companies with negative NTM FCF are not listed on the chart

Scatter Plot of EV / NTM Rev Multiple vs NTM Rev Growth

How correlated is growth to valuation multiple?

Operating Metrics

• Median NTM growth rate: 12%

• Median LTM growth rate: 14%

• Median Gross Margin: 76%

• Median Operating Margin (4%)

• Median FCF Margin: 18%

• Median Net Retention: 108%

• Median CAC Payback: 38 months

• Median S&M % Revenue: 38%

• Median R&D % Revenue: 24%

• Median G&A % Revenue: 16%

Comps Output

Rule of 40 shows rev growth + FCF margin (both LTM and NTM for growth + margins). FCF calculated as Cash Flow from Operations - Capital Expenditures

GM Adjusted Payback is calculated as: (Previous Q S&M) / (Net New ARR in Q x Gross Margin) x 12. It shows the number of months it takes for a SaaS business to pay back its fully burdened CAC on a gross profit basis. Most public companies don’t report net new ARR, so I’m taking an implied ARR metric (quarterly subscription revenue x 4). Net new ARR is simply the ARR of the current quarter, minus the ARR of the previous quarter. Companies that do not disclose subscription rev have been left out of the analysis and are listed as NA.

Sources used in this post include Bloomberg, Pitchbook and company filings

The information presented in this newsletter is the opinion of the author and does not necessarily reflect the view of any other person or entity, including Altimeter Capital Management, LP ("Altimeter"). The information provided is believed to be from reliable sources but no liability is accepted for any inaccuracies. This is for information purposes and should not be construed as an investment recommendation. Past performance is no guarantee of future performance. Altimeter is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration does not imply a certain level of skill or training. Altimeter and its clients trade in public securities and have made and/or may make investments in or investment decisions relating to the companies referenced herein. The views expressed herein are those of the author and not of Altimeter or its clients, which reserve the right to make investment decisions or engage in trading activity that would be (or could be construed as) consistent and/or inconsistent with the views expressed herein.

This post and the information presented are intended for informational purposes only. The views expressed herein are the author’s alone and do not constitute an offer to sell, or a recommendation to purchase, or a solicitation of an offer to buy, any security, nor a recommendation for any investment product or service. While certain information contained herein has been obtained from sources believed to be reliable, neither the author nor any of his employers or their affiliates have independently verified this information, and its accuracy and completeness cannot be guaranteed. Accordingly, no representation or warranty, express or implied, is made as to, and no reliance should be placed on, the fairness, accuracy, timeliness or completeness of this information. The author and all employers and their affiliated persons assume no liability for this information and no obligation to update the information or analysis contained herein in the future.