Your Data Layer Used to Hide Behind Your Product. Now It Is the Product. With Firebolt’s CEO

For most of B2B history, customers never knew or cared what database ran under your product. They consumed the UX, maybe an API, and the data layer sat invisibly in the back. Benjamin Wagner, CEO of Firebolt, came to SaaStr AI to argue that this is over. As agents start hitting products directly, the data layer moves from plumbing to the thing customers and their agents judge you on. He walked through three shifts already breaking products in the field.

Shift one: where your software runs is changing

The first crack is deployment. One Firebolt customer had a couple of months to move their entire product onto CoreWeave to chase an opportunity, and is now eyeing other neoclouds. That kind of scramble is becoming normal. More structurally, Fortune 100, public sector, and heavily regulated buyers increasingly refuse to let their data leave their environment. They want bring-your-own-cloud, air-gapped, and on-prem deployments, with control over exactly what the vendor can see. The more sensitive the data, the harder that line gets.

The consequence is blunt. If your data plane cannot follow your product into the customer’s environment, you will not close those deals. And the common workaround makes things worse: a fragmented backend where a dev laptop runs one database, your cloud runs another, and the customer’s data center runs a third. Each behaves differently, so a simple schema migration becomes three problems, and the product experience splinters depending on which engine is underneath. Wagner’s answer is to build on open-source analytical databases for deployment flexibility, which is why Firebolt is open-sourcing nearly everything. If a customer cannot work with you as a managed vendor, you want them able to run the open-source version rather than walk.

Shift two: your own team’s agents write against the data layer

The second shift is internal. Your engineers now build with coding agents, and a large share of that work is written against your data layer. Wagner’s case for open source extends here. Coding agents work better against open systems because they can read the code, the tests, and the GitHub issues directly, none of which they can do against a closed product. They also reward fast local iteration, so being able to spin up a local binary of your database to work out the dialect, schema evolution, and table operations beats trying to imitate the system through MCPs and CLIs.

He added a standards point worth heeding. Pick database vendors that speak a common language, and avoid the ones with their own SQL dialect, because a custom dialect becomes a constant tax once agents are the ones writing the queries.

Shift three: your customers’ agents want in too

The third shift is the most disruptive. Your customers’ agents do not want your UI. They do not want your five static dashboards. They want direct access to the underlying data, usually through a query interface. And the moment you expose a SQL-like interface into your core data, you have become a database vendor, with all the hard problems that come with it: resource isolation so one startup spawning agents cannot take down your Fortune 500 customers, autoscaling, and reliability when the thing breaks at 2am.

That is the heart of the talk. The data layer used to be the part nobody saw. Now it is the surface customers and their agents interact with, query, and judge. It is the product.

The demo that broke, and why that fits

Wagner had vibe-coded a live demo to show all of this, and it broke on stage. He handled it plainly: this is what happens when you let agents vibe-code the demo you are about to give live. It was an honest moment that underlined the larger point. The shift to agent-built, agent-queried software is real and powerful, and it is still raw enough that the seams show. The teams that win will be the ones building for that reality now, not the ones waiting for it to feel finished.

The data layer is the new moat

Stack the three shifts together and the strategic read is clear. The data layer is moving to the center of the product, the deal, and the buying decision. Deployment flexibility decides which enterprise deals you can even compete for. Open source decides how fast your own agents can build. And a clean, queryable data layer decides whether your customers’ agents get a good experience or a broken one. If you have treated the database as an implementation detail, that detail just became your moat or your ceiling.

Top 5 takeaways

The data layer is becoming the product. It used to hide behind the UX, but customers and their agents now query and judge it directly, so it sits at the center of the experience.Your data plane has to follow your product. Enterprise, public sector, and regulated buyers increasingly demand bring-your-own-cloud, air-gapped, or on-prem deployments, and if your data layer cannot move with you, you cannot close those deals.Fragmented backends are a tax. Running different databases on the laptop, in your cloud, and in the customer’s data center turns simple changes into three problems and splinters the product experience. One system across all environments beats stitching several together.Open source compounds in the agent era. Coding agents work better against open systems because they can read the code, tests, and issues, and local binaries enable the fast iteration agents thrive on. Avoid vendors with a custom SQL dialect.Exposing a query interface makes you a database vendor. Once customers’ agents query your data directly, you inherit resource isolation, autoscaling, and 2am reliability, so plan for those problems before you ship the interface.