Databricks Gets More Queries From Agents Than People on a Meter With No Seats
Agents now send Databricks more queries than people, an a16z essay says. Lakebase, its Postgres database built for them, passed a $100 million run rate in August.
TL;DR
- An a16z essay says agents now send Databricks more queries than people and launch over 17 million databases daily.
- Databricks bills compute by the second with no seats, so agent workloads drive a growing share of customer usage.
- Databricks hasn't disclosed how much revenue agents drive; Lakebase, built for agents, is about 1.4% of its $7 billion run rate.
Ben Horowitz sits on Databricks' board, and his firm a16z led its Series A in 2013. He wrote on October 27 that Databricks now sees more queries from agents than from people. In the same essay, written with a16z's Michael McGuiness, he said agents launch more than 17 million databases a day on the platform. Three years ago, he wrote, every interaction on Databricks involved a human. The revenue figures in the essay aren't new. Databricks said on August 13 that it had passed a $7 billion run rate growing more than 80% a year. It also said Lakebase, its Postgres database built for AI agents, had passed a $100 million run rate.
The new part is who's doing the querying, and Databricks charges for the work rather than the user. Its pricing page bills compute by the second in units it calls DBUs, with discounts for committed usage and no per-user seat. On that meter a customer's bill follows how much work its agents run rather than how many employees log in. In December, Databricks reported a $4.8 billion run rate growing 55%, net retention above 140% and more than 700 customers consuming over $1 million a year. By August growth had reached 80%, with more than 1,000 customers above $1 million and more than 100 above $10 million. Databricks hasn't said how much of that acceleration came from agent workloads.
Databricks' own research says agents mostly spin up test environments
Databricks' State of AI Agents 2026 report says agents create 97% of database testing and development environments. It describes them as ephemeral places to test and experiment. The same report says only 19% of organizations have deployed AI agents, mostly to a limited extent. A database count measures how often agents spin something up, which is a different number from what the customer pays.
Other platforms describe the same pattern. Supabase CEO Paul Copplestone wrote on October 2, in Supabase's post announcing its Turso acquisition, that agents are spinning up millions of databases for "prototypes, explorations, dashboards, and apps." At MotherDuck, AI lead Till Döhmen wrote in July that agents run more queries than people do through the web app. They often fire many at once, where an analyst runs one query and reads the result.
Set those agent figures against revenue and the gap shows. Lakebase, the product Databricks built for agents, is about 1.4% of the $7 billion total. A count of 17 million databases a day says how often agents launch something and nothing about what any of it bills. Databricks hasn't published revenue per query, the share of revenue agents drive or its gross margin. Every figure here is company-stated by a private company, and in this case relayed by an investor.
None of that makes the shift small. Lakebase was built with the agent as its user and passed $100 million about a year after its 2025 launch. Databricks said in December that Lakebase revenue was growing at twice the pace of its data warehousing business. Agents set the volume. The price per unit of agent work decides how much of that volume becomes revenue. Exa reached $100 million selling searches to agents by the request, where every agent call is a billable request.
What this means for RevOps teams forecasting usage revenue
If your product bills on consumption, next quarter's number now depends partly on how many agents your customers point at it. Start by splitting usage telemetry into human and agent traffic. You'll then see when the agent share passes the human one in your own logs, as it already has at Databricks and MotherDuck.
Then forecast on billed conversion instead of raw activity. Pick the unit that actually invoices (an agent-run job, or an agent-created database that's still running a week later) and measure revenue per unit before you plan on it. A count of agent sessions will overstate your pipeline, the same way 17 million databases a day says little about Lakebase's $100 million.
Comp follows from the same split. On usage deals, most of a rep's variable pay should follow consumed revenue. On an agent-heavy account, the rep grows that revenue by getting more of the customer's agents onto the product, since there are no seats to add. At your next business review with a large customer, ask how many agents they plan to run against your product next quarter. If they can't answer, your forecast for that account rests on a guess.
Our guess is that Databricks' next revenue update still won't split agent consumption from human use. Until a vendor that size does, agent counts tell you about volume and little about bills.
