Every enterprise eventually runs into the same wall, whether we look at analytics or AI workloads. The data needed to answer a question, contextual data, rarely lives in one place. Instead, it sits across multiple data sources, including data lakehouses, operational databases, data warehouses, live services, and, increasingly, customers’ own systems. The traditional answer is data centralization. This means copying everything into a single data warehouse before it can be queried, but that approach trades flexibility for control while adding cost, latency, and lock-in along the way.
There is a better way. Starburst was founded on it, and our customers are living proof.
How Rippling solved the context problem
Rippling chose an open, federated data foundation instead of data centralization. As the platform that unifies HR, IT, and Finance on a single source of truth, Rippling needed a data foundation that could match the breadth of its product. That meant a foundation open enough to reason over data wherever it lives, and robust enough to do so at product-grade scale across millions of queries a day. This is exactly the kind of problem query federation is built to solve.
That foundation is built using Starburst, exemplifying how we think about the modern data platform at Starburst. At its heart this is about choice. A compute engine should meet data where it already lives, limiting the need to copy it from system to system. It should stay open, so teams are never locked into a single proprietary architecture. As we’ve written before, portability was always the point. Further, it should give engineering teams room to extend and build on it, not just query through it. Rippling has done exactly that, using Starburst alongside its own business semantics, connectors, and query language, on a platform Rippling operates in its own environment.
In this post, the Rippling Data Cloud team walks through how they built this platform and why it operates effectively. They explain why they chose an open, federated model over centralization, what they added on top of Trino to fit their product domain, and how the combination of Rippling’s engineering and the Starburst platform delivers a shared, reliable execution layer across HR, IT, and Finance.
One platform, one source of truth built across multiple data sources
Rippling gives businesses a single place to run HR, IT, and Finance — all built on a unified source of truth for employee and business data.
When a payroll admin opens a real-time dashboard, when an IT leader investigates device compliance, when a finance team builds a compensation report, when a customer creates their own report, or when an AI workflow reasons over business context, the same question appears again and again:
Can we answer this instantly, using data that may live across many different systems?
Rippling Data Cloud exists to answer that question.
A key part of this foundation is Starburst. Starburst gives Rippling the ability to query data across systems without first copying everything into one place, while providing an enterprise-grade platform for operating that engine reliably, securely, and at scale.
The result is a data architecture that is open, flexible, and deeply integrated into Rippling’s product experience.
Figure 1: Rippling Data Cloud uses RQL to power product experiences across HR, IT, Finance, reporting, and AI workflows. RQL translates business logic into distributed SQL that runs on Starburst, where Rippling’s custom types, UDFs, dynamic connection passthrough, and performance optimizations help query data across Iceberg, operational databases, Snowflake, and live services.
Why Rippling built on Starburst
Employee and business data does not live in one place.
Some data sits in Rippling’s Apache Iceberg lakehouse on Amazon S3. Some live in operational PostgreSQL databases. Some live in customers’ Snowflake environments. Some live behind live services. Some belong to customers and external systems. Traditional analytics architectures often solve this by copying data into a single warehouse before it can be queried.
That model creates familiar problems, including:
- Data movement adds latency.
- Duplication increases cost.
- Centralization can create lock-in.
- Product teams lose flexibility.
- Live operational context becomes harder to combine with historical analysis.
Starburst offered Rippling a better model, the ability to query data where it already lives, then blend it together in a single distributed query.
Because Rippling’s lakehouse is built on Apache Iceberg, the data stays open. Multiple engines can read it, and the platform is not boxed into a single proprietary architecture.
Starburst brought that open query model into an enterprise-grade form. As a platform built by the creators of Trino, Starburst gives Rippling the operational foundation needed to run Trino in Rippling’s own AWS environment, on Rippling’s terms, with the support and platform capabilities expected for business-critical infrastructure.
For Rippling, this combination matters because Starburst is not just an analytics tool. It is a substrate for product development.
What Rippling built on top
A query language built for Rippling
Much of Rippling’s analytical surface is expressed through RQL, the Rippling Query Language.
RQL is used by Rippling users and developers to build formulas, reports, applications, and analytics-powered product experiences. Under the hood, RQL compiles into distributed Trino SQL, the underlying flavor of SQL used by Starburst.
That means many analytical experiences across Rippling can run on the same fast, federated engine — from a simple formula to a complex customer-authored report.
This gives Rippling a consistent execution layer for product analytics, customer reporting, internal reporting, and future AI-driven experiences.
Native support for Rippling-specific business concepts
Starburst’s openness was especially important because Rippling needed the engine to understand business concepts that are central to HR and Finance.
Financial data is everywhere in Rippling. But an amount plus a currency type is awkward to model as a generic row, such as ROW(VARCHAR, DOUBLE). That representation can store the data, but it does not give the engine the right semantics for arithmetic, aggregation, or comparison.
Rippling extended built-in support with two native column types: currency and timestamped_currency. These are registered through the underlying Trino Type SPI and include custom binary serialization, arithmetic operators, and aggregation functions within Starburst.
With these native types, money behaves like a first-class analytical value inside the query engine. Teams can use operations like SUM, AVG, MIN, and MAX directly on currency columns, with the correct semantics, instead of unpacking generic structures that the engine cannot aggregate cleanly. These operations can also work across currencies, with conversion handled directly inside Starburst through custom-built Rippling primitives — making multi-currency analytics native to the query layer rather than something each application has to solve on its own.
This is a good example of why Rippling’s collaboration with Starburst is valuable. The platform is open enough to adapt to Rippling’s product domain, not just generic analytics use cases.
User-defined functions that run inside the engine
Rippling also added a custom user-defined function plugin for work that needs to happen close to the data.
These functions include:
- Fernet decryption for protected fields
- Rippling-specific date and epoch conversions
- Business-day date arithmetic
- Custom percentile calculations
By running this logic inside Starburst, Rippling can avoid pushing sensitive or high-volume analytical work into separate services. Decryption, for example, executes inside the engine itself rather than in a Lambda, sidecar, or external service.
That keeps sensitive work within the same trust boundary as the query, while also simplifying the architecture for product and analytics workloads that need this logic at query time.
Virtual Tables for live service data
Not every piece of useful data is materialized into a datastore.
Some data lives behind live services and needs to be queried in real time. To support that, Rippling built Virtual Tables: a custom Trino connector that takes an OpenAPI specification and exposes REST service endpoints as SQL tables.
This lets RQL query live service data using the same relational pattern it uses for other datastores. For developers and users, service-backed data can appear as queryable tables even when it has not been materialized into a datastore.
Virtual tables expand the reach of Rippling’s analytical layer beyond traditional data stores and help bridge the gap between operational services and analytical product experiences.
Running reliably at scale
Rippling runs this foundation across a large fleet of Starburst clusters supporting both interactive and batch workloads. To keep the platform fast and always-on as it grows, Rippling combines gateway-based routing, fault-tolerant execution, and internal deployment automation.
Trino Gateway for routing and availability
Rippling routes traffic through Trino Gateway, giving users and systems a single endpoint while allowing the platform to direct each query to the right cluster behind the scenes.
This helps Rippling support multiple workloads, add capacity, and roll out upgrades with minimal disruption. It also gives the platform team more flexibility to evolve the fleet without changing how downstream users and applications connect to Trino.
Fault-tolerant execution for long-running workloads
For long-running workloads, such as batch and transform jobs that may run for hours, Rippling uses Starburst’s fault-tolerant execution.
If a worker is lost or a spot instance is reclaimed mid-query, the engine can retry the affected tasks and continue instead of failing the full job. That means large jobs can finish more reliably, even on elastic infrastructure.
Automated zero-downtime deployments
Overall, Starburst powers critical interactive and batch workloads across 80+ production clusters at Rippling. As that fleet grows, manual deployments become a bottleneck — both for the platform team and for the customer-facing workloads that depend on consistent uptime.
To solve this, Rippling built an internal Kubernetes operator that automates zero-downtime deployments. The operator provisions the replacement cluster, verifies health, switches traffic through Trino Gateway, and drains queries from the old cluster before scaling it down. New traffic is only routed once the new cluster is healthy, and the old cluster stays up until its query queue reaches zero.
This gives Rippling a safer operating model for a growing Starburst fleet. This means fewer manual deployment steps, lower risk of query interruption, and the ability to scale the platform without scaling operational toil.
How Starburst Enterprise makes this possible
Rippling uses Starburst Enterprise to focus more of its engineering energy on product capability and platform differentiation, while relying on Starburst for key enterprise capabilities around their Trino deployment.
Important areas include:
Parallel connectivity
Starburst’s parallel connectors help improve throughput for connected systems such as Snowflake, where standard JDBC-style access may not be sufficient for large-scale data movement or analytics.
Iceberg support
Rippling’s lakehouse is built on Apache Iceberg, and Starburst supports the performance and operational needs of an open lakehouse architecture, including capabilities such as materialized views and table maintenance.
Dynamic connection passthrough for customer-scale federation
Rippling serves many customers, each with their own external data sources and access patterns.
Standing up a dedicated catalog for every customer and every connector would not scale operationally. As the fleet grows, that model creates several challenges:
- Customer actions such as connecting, disconnecting, or rotating credentials for a data source would require catalog changes to be coordinated across 80+ production clusters.
- Each cluster would repeatedly pay startup and registration overhead for catalog definitions that exist only to route customer-specific connections.
- Credential rotation would become tied to cluster redeployments, increasing operational complexity for both customers and Rippling.
Instead, Rippling uses Starburst’s dynamic connection passthrough capability to support customer-scale federation across data sources. With this model, a single catalog pattern can route each query to the right source with the right credentials, without requiring cluster redeployments when customer-side connections change. The result is a method of credential passthrough that ensures security based on the session options specific to the query.
For Rippling, that means fewer catalogs to operate, cleaner customer-specific access patterns, easier credential rotation, and a more scalable foundation for connecting trusted business data across systems, while preserving per-query security through session-scoped credentials.
For Rippling, that means fewer catalogs to operate, cleaner customer-specific access patterns, easier credential rotation, and a more scalable foundation for connecting trusted business data across systems.
For a platform like Rippling Data Cloud, this matters because the long-term goal is not simply to query one lakehouse. It is to make trusted business data available across many systems, many products, and many customers.
Enterprise deployment model
Starburst Enterprise runs in Rippling’s own AWS environment. That gives Rippling control over infrastructure, security, and operating model while still benefiting from an enterprise-grade Trino deployment.
Support from the Trino experts
Starburst was founded to be the best Trino deployment possible. For a company extending open source’s Trino functionality through custom types, functions, connectors, and query patterns, that expertise is valuable.
Why this matters for Rippling Data Cloud
Rippling Data Cloud is not just about analytics infrastructure. It is about giving every part of the product a stronger data foundation.
With Starburst, Rippling can:
- Query data where it lives
- Keep the lakehouse open with Apache Iceberg
- Power RQL across product surfaces
- Extend the engine with Rippling-specific business semantics
- Support real-time, customer-authored, and AI-driven analytical experiences
- Operate the platform reliably at enterprise scale
This is the kind of foundation required for a product suite that spans HR, IT, and Finance.
The collaboration with Starburst helps Rippling deliver on the Data Cloud vision: one trusted data foundation for operational workflows, reporting, analytics, and intelligent automation across the business.
Impact
Rippling’s Starburst-powered analytics platform now operates at product-grade scale:
- O(10 million) queries per day: The platform serves millions of queries daily across critical interactive and batch workloads.
- ~2 second P95 latency for interactive analytical queries: Interactive workloads remain responsive for product teams, customers, and internal users.
- 80+ production clusters: Trino serves as the backbone of Rippling’s OLAP stack across a large and growing production fleet.
- Lower operational toil: With Starburst Enterprise, custom Trino extensions, gateway-based routing, and Rippling-built deployment automation, the platform can continue scaling without a matching increase in manual operations.
Together, these capabilities give Rippling a shared, open, and reliable execution layer that extends beyond HR, IT, and Finance, reliably querying complex customer-specific schemas and third-party warehouses as easily as Rippling’s core data.
Rippling and Starburst: A Powerful Match
Rippling’s engineering team knew exactly what they wanted to build. They needed a partner whose platform was open enough to let them build it. That is what makes this collaboration work. Starburst provides the enterprise foundation, the parallel connectivity, the Iceberg support, the dynamic connection passthrough, and the operational reliability, while Rippling brings the deep product knowledge to extend that foundation with native currency types, custom functions, virtual tables, and RQL.
Rippling’s extensions are powerful because they run on a platform built and supported by the people who know it best, and Starburst grows stronger as customers like Rippling push it into new territory. That is the kind of collaboration we value most, one where the platform gives teams room to build and the results speak for themselves. We are proud to help power Rippling Data Cloud, and excited to see where the team takes it next. To explore what Starburst could do for your data, explore Starburst Enterprise.
