This is Pulumi’s page, Starburst. The canonical URL is /customers/starburst/. Matt Stephenson, Senior Principal Software Engineer at Starburst, is the person they quote.
Galaxy is their managed Trino service. It runs in 22 regions on AWS, Azure, and GCP, across 50 to 60 Kubernetes clusters. The control plane is mostly EKS. Each service is a Java Airlift app on a cluster. A platform team owns the infrastructure. A service team ships Galaxy on top of it.
The Terraform → Pulumi playbook is state, providers, and secrets. This page is a vendor’s speed claim, and the claim is worded more than one way.
Read the quote, then the headline
Stephenson says:
When we did it with Terraform, it took two weeks to do [infrastructure deployments]. Now we do it in about three hours a day.
The headline and the key stats say something tighter. Two weeks became 3 hours, and they call that 112 times faster. The body says the same three hours for Galaxy’s multi-region blue-green deploys, and it credits full automation of the pipeline, so nobody runs glue scripts by hand. The closing section also says a 99% reduction in deployment time.
I would not merge “about three hours a day” with “three hours” or with 112x. They are all on the page. They are not the same sentence. There is no dollar figure next to any of them.
What Terraform was doing
A Galaxy deploy was blue-green. New Kubernetes clusters in every region, new services, then delete the old clusters. With Terraform that took two weeks, because of glue scripts and manual runs. GitHub Actions was hard to hang off Terraform, so scaling to another region stayed manual. HCL made it hard to hide the differences between EKS, AKS, and GKE behind one abstraction. Service developers filed tickets. A review environment could take an hour, and even a Terraform template still needed per-environment config.
What they run now
Pulumi programs are in a monorepo. Stephenson’s team used Java, so clusters and managed services became ordinary objects, with shared functions for autoscaling, upgrades, and node groups. Deploys go through the Automation API, triggered by GitHub Actions. A service developer changes a list and opens a pull request. The workflow creates the infrastructure.
In 2023 management wanted to cut cost, and they left Pulumi Cloud for a state bucket they ran themselves on S3. Replacing the cloud product took, on average, two engineers for one or two days a week. They came back. The page says the cloud product pays for itself because the dashboard shows unused resources they can turn off. Still no dollar amount.
Several later gains are plans. They intend to run Pulumi Deployments so a lost GitHub Actions Spot instance stops interrupting an update. They say a test stack that took an hour will take half that with review stacks and a TTL. They plan to use ESC so developers stop copying keys out of KMS. Drift detection is described with an on-call story about a manual change, not with an incident count. Pulumi AI, they say, turned an AWS VPC and EKS rewrite that would have taken a couple of months into a week or two. A stats line calls that a factor of ten. Same rewrite, two phrasings.
If you use this page in a proposal, paste Stephenson’s sentence and the 112x line as two quotes. The playbook will not tell you which one your pipeline will hit. A rehearsal on one region will.