Skip to main content
nOps logo

CUSTOMER STORY

nOps unifies its real-time stack and cuts costs 6x with Lakehouse//RT

Two people pointing at code on monitors.

Over 6x

lower infrastructure costs

40TB

duplicated data eliminated

Zero

data movement required

Every cloud bill tells a story, but reading it can require translating millions of line items from dozens of cloud and AI providers into something a CFO, an engineering lead, or a FinOps team can actually act on. That's the problem nOps solves. The company's platform manages more than $5 billion in annual cloud spend for hundreds of customers, turning raw billing and usage data into real-time dashboards where enterprises can see exactly where their money goes, down to the department, cost center, or custom tag. 

Customers expect that visibility to be immediate. When a commitment recommendation changes, when spending spikes in an unexpected account, or when a new AI workload starts driving costs, the dashboards need to reflect it in real time. nOps provides customizable dashboard views, and the data behind them has to stay fresh and responsive across every customer's unique configuration. As a Built on Databricks partner, nOps recently replaced Apache Druid with Lakehouse//RT to power that real-time layer while cutting infrastructure costs and consolidating architecture onto a single governed platform.

Building a real-time layer for the next generation of enterprise customers

For years, the real-time query layer behind nOps's customer dashboards ran on Apache Druid. The company started with a self-hosted deployment, then moved to a managed Druid service. But as the platform grew and enterprise customers brought increasingly complex reporting requirements, the gap between what the business needed and what Druid could deliver widened.

"We just couldn't get the performance we needed," said Jordan Stein, Director of Engineering at nOps. "And it was really hard to get the value out of it." The challenge wasn't just speed. nOps lets customers define their own mappings, tags, and groupings, so no two customers' dashboards look the same. The queries powering those views can be highly complex, some as long as 30,000 lines of SQL with string matching across trillions of rows. As nOps landed larger enterprise accounts with more departments, more cost centers, and more granular reporting requirements, the queries grew longer and more demanding. These were the customers nOps most wanted to serve, and the existing real-time layer was holding the platform back.

The team needed a platform that could handle the full complexity of those queries without requiring nOps to move its data out of S3. With roughly 380TB of cloud infrastructure data in S3 powering its Delta tables, duplicating it into a separate serving layer added cost, latency, and operational overhead that the team wanted to eliminate entirely.

Lakehouse//RT: Zero data movement, instant rollbacks

nOps was already using Databricks metric views in production and running its application database on Lakebase when Lakehouse//RT launched. The timing aligned perfectly with the team's search for a new real-time engine. "This was exactly the problem we were trying to solve," Stein said. "From the moment we got access, it was clear that Lakehouse//RT was a direct replacement for our Druid layer."

The most critical requirement was zero data movement. nOps has roughly 380TB of data in S3, and duplicating it into a separate serving layer was expensive and operationally painful. Lakehouse//RT queries the same Delta tables directly, with no copying, no ingestion pipelines, and no secondary storage. "Anyone would know that trying to move over 380 terabytes of data around to different platforms is a nightmare, and it's expensive," Stein said. "With Lakehouse//RT, it required zero change to the underlying data."

The migration also unlocked instant table version rollbacks. On Druid, rolling back a table version meant submitting a new ingestion job and waiting up to three hours. With Lakehouse//RT reading directly from Delta tables, rollbacks happen immediately. "That's one of the most impactful changes for us," Stein said. "The data the customer sees is the same table we just finished writing to. We don't have to chase a duplicate of that data sitting in another location."

Over 6x cost reduction and a unified data platform

The financial impact has been substantial. nOps's previous architecture relied on always-on Druid clusters. With Lakehouse//RT's serverless autoscaling, the team reduced real-time infrastructure spend to roughly 16% of the previous cost, or more than 6x less expensive. The migration also eliminated 40TB of duplicated serving data that had been stored outside S3 in the secondary Druid storage layer. 

Beyond dashboards, nOps also routes its internal AI agents and MCP (Model Context Protocol) architecture through Lakehouse//RT, which has significantly improved response times and the quality of the conversational chat experience for customers. "Having the underlying data be the same between what we're writing into on the backend and what the customer sees on the frontend is huge," Stein said. "There's a lot of value in moving these codependent architectures into one place."

As a Built on Databricks partner, nOps's experience illustrates why Lakehouse//RT is well suited for ISV partners building data-intensive applications. Observability and cloud cost management platforms deal with massive data volumes, complex customer-defined queries and the expectation of real-time responsiveness. Lakehouse//RT lets ISVs serve those workloads directly from the lakehouse without maintaining a separate real-time database, reducing both infrastructure costs and operational complexity. The close collaboration nOps had with the Databricks product team during the beta further accelerated the migration. "That sort of partnership is very valuable when you have teams that can push the new technology and provide valuable feedback," Stein said.

nOps replaced its managed Apache Druid real-time query layer with Databricks Lakehouse//RT, powered by the Reyden engine. Lakehouse//RT queries the same Delta tables stored in S3 directly, eliminating the need for a separate serving database, data duplication and ingestion pipelines.

Want to learn more about Lakehouse//RT?