How nOps Rebuilt Their Cloud Optimization Platform on Databricks Lakebase, and Why Other ISVs Should Too

nOps, a Databricks Built On partner managing over $4 billion in annual cloud spend, migrated their production application to Databricks Lakebase. The result was a faster, simpler architecture that eliminated the glue between their app and their analytics, and a playbook for ISVs looking to do the same.

Every ISV building on Databricks eventually hits the same architectural crossroads: your analytics live in the Lakehouse, but your application needs a relational database for low-latency reads and writes. So you bolt on a separate Postgres instance (maybe RDS, maybe something self-managed) and suddenly you're maintaining ETL pipelines, cron jobs, and change-detection logic just to keep two systems in sync.

nOps lived that reality for years. And then they found a better way.

nOps: Automating Cloud Savings at Scale

For those unfamiliar, nOps is an automated cloud cost optimization platform that manages commitment-based discounts across AWS, GCP, and Azure. Their approach is distinctly "always-on." They monitor, purchase, and exchange cloud commitments on an hourly basis, using machine learning to balance effective savings rates against commitment lock-in risk. The model is performance-based: nOps only charges a percentage of the incremental savings they generate.

It's a data-intensive operation. Every hour, nOps analyzes usage patterns across thousands of customer accounts, evaluates commitment portfolios across three major cloud providers and dozens of services, and makes automated purchasing decisions. On top of that, they surface cost visibility, forecasting, and anomaly detection through a centralized FinOps platform.

The analytical backbone for all of this has long been Databricks Lakehouse. But the front-end application, the platform customers log into to see their savings, manage budgets, and explore cost data, needed something more.

The Problem: Two Worlds, Loosely Connected

nOps's previous architecture was a familiar pattern for ISVs on Databricks. Advanced analytics and metric computation ran in the Lakehouse. Customer-facing data (account configurations, user preferences, rapidly changing client-specific state) lived in a separate relational database powered by third-party vendors and homegrown solutions.

The seams between these two systems created real friction. Scheduled jobs and cron-based change detection were required to keep the front-end database and the Lakehouse in sync. Data that was "live" in one system might take minutes or longer to appear in the other. And the operational overhead of managing a separate database stack, with its own scaling, backup, and security concerns, pulled engineering time away from what nOps actually does best: building commitment automation.

When nOps expanded from AWS-only to multi-cloud coverage across GCP and Azure in early 2026, the growing workloads strained this architecture. The team decided to rebuild the platform, this time focusing on their specialty and choosing infrastructure that simply works.

The Decision: Why Lakebase

nOps selected Databricks Lakebase, a fully managed PostgreSQL database integrated directly with the Lakehouse, as the OLTP backbone for their new platform.

Jordan Stein, Director of Product at nOps, pointed to three factors that made Lakebase the right fit:

• Tight coupling to the Lakehouse. This was the biggest factor. With Lakebase, nOps's data engineering teams can immediately access frequently changing customer data from their Lakehouse pipelines without scheduled jobs, crons, or lag. As Jordan put it: "We're talking scheduled jobs that had to run, crons that are coming and picking up those changes, whereas now we know that the moment it's live, we can consume it. This has been a game changer for us."
• Auto-scaling and auto-stop. Even with aggressive auto-stop settings during development, the nOps team was "shocked by the performance." Lakebase's serverless compute adjusts to workload demands and scales to zero when idle, which matters for a cost-optimization company that practices what it preaches.
• Ease of adoption. Point-in-time restore has already proven valuable. Flexible OAuth roles simplify access control. And because Lakebase lives within the Databricks workspace, their teams are working in a platform they already know. No new tool to learn, no separate console to manage.

The Architecture: One Platform, Tightly Integrated

Here's what nOps's new architecture looks like:

Lakebase serves as the central Postgres database and single source of truth for both the front-end application and their AI infrastructure.

Databricks Lakehouse continuously consumes data from Lakebase for analysis and metric computation.

The nOps platform automatically discovers and surfaces Databricks Metric Views, so standardized metrics computed in the Lakehouse show up consistently in the front-end.

Data flows in one direction, from Lakebase into the Lakehouse for analytics, with no direct write-back needed. This keeps the architecture clean and the source of truth unambiguous.

The rest of the stack follows the same approach: Vercel for hosting and observability, WorkOS for authentication, and Databricks for everything data.

Hear It from nOps

Jordan Stein recently walked through the full nOps Lakebase migration story in a partner spotlight presentation. Watch the video to hear how the transition went, what surprised them about performance, and how the Lakehouse integration changed their data engineering workflows:

The ISV Playbook: Why Lakebase Changes the Game

nOps's story isn't unique. Nearly every ISV building on Databricks faces the same OLTP-meets-analytics tension. What's worth paying attention to is how cleanly Lakebase resolves it.

Eliminate the sync tax. The most expensive code in any ISV's stack is often the code that moves data between systems. Lakebase's native integration with Unity Catalog and one-click Delta Lake sync replaces custom ETL pipelines with managed infrastructure. That's engineering time you get back.

One governance model. When your OLTP database is registered as a Unity Catalog asset, you get unified governance, lineage, and access control across operational and analytical data. No more managing security policies in two places.

Postgres compatibility means zero rewrite. Lakebase is fully managed PostgreSQL. Your existing libraries, ORMs, and SQL tools work out of the box. Extensions like pgvector and PostGIS are supported. You migrate by pointing your app at a new connection string, not by rewriting queries.

Scale economics that make sense. Usage-based pricing with scale-to-zero means you're not paying for idle capacity. For ISVs with variable workloads (and which ISV doesn't have variable workloads?) this directly impacts unit economics.

Ship faster. When your application database and your data warehouse are the same platform, an entire category of integration work disappears. Your team ships features instead of maintaining plumbing.

Early Adopters, Real Impact

nOps is a good example of what an innovative Built On partner looks like. Rather than waiting for Lakebase to mature through multiple release cycles, they recognized the architectural fit early, committed to a production migration, and are already seeing results: faster data pipelines, lower operational overhead, and a better experience for their customers.

That willingness to move early is strategically smart too. By building on Lakebase now, nOps has a tighter integration with the Databricks platform than competitors who are still duct-taping separate database stacks together. Their platform is simpler to operate and faster to extend.

Get Started

Explore Lakebase. If you're an ISV building on Databricks, or considering it, learn more about Lakebase and how it can simplify your architecture.

Explore nOps. If your organization is looking to reduce cloud costs across AWS, GCP, or Azure without the commitment risk, visit nOps to see how their automated optimization platform, now powered by Databricks Lakebase, can help.