Oracle has spent the last two weeks writing articles comparing Oracle (and PDB) to Lakebase, and it highlights a massive philosophical divide in how we view databases in the agentic era. They are trying to retrofit heavy, traditional architectures for AI. We believe Lakebase are the future because agents need something entirely different: ⚡️ Super simple APIs: so agents don't have to read a giant manual and hallucinate a query. ⚡️ Sub-second provisioning & auto-scaling: so you aren't paying legacy-level prices for idle time. ⚡️ Branching: Git-style branching to create isolated, safe environments for agents on the fly. ⚡️ Automatic backup & restore: so you don't sweat it when an autonomous agent inevitably drops a table. The numbers speak for themselves. Lakebase is our fastest growing product. In the last few months alone, we've seen database start rate 30X, and now we are starting tens of millions of databases EVERY DAY. Some of these databases have 500 level deep branches and lifetime of just seconds due to how fast agents move. Go try it yourself in a few seconds on neon.com! The team has been cooking hard to push this gap even further. Come to Data and AI Summit next month to hear about some major new breakthrough capabilities. 🚀 (Links in comments so you can read their take)
Eugene T.
1w
Read that sentence again. "So you don't sweat it when an autonomous agent inevitably drops a table." You're not selling a database feature. You're admitting your agents destroy data by design and you've built a cleanup abstraction around it. That's not engineering. That's an apology with a marketing team. The part nobody's saying: if you're spinning up tens of millions of databases with lifetimes measured in seconds, you've built the most expensive garbage collector in history. What are those agents actually DOING with that data, or is this just chaos at scale with an undo button? "Agents need something different" is true. I'm just not sure "something that deletes itself" was the answer we were looking for.
The "automatic backup and restore" for when an agent inevitably drops a table is a lifesaver. It raises an interesting technical question, though: when an agent causes a failure mid-transaction on a deep branch, how does Lakebase handle partial state recovery without rolling back valid parallel agent workflows? Traditional DBAs would sweat bullets over this, so curious how you've abstracted that complexity away!
500 branches deep but lasting seconds. That’s wild. Agents are treating databases like throwaway compute. We optimized for persistence for decades but now the game is speed. Lakebase is perfect for this agentic era! Looking forward to seeing what’s next at the Data and AI summit!
Biswa Nag
6d
Autonomous agent "inevitably" drops a table? Wonder whose job it is to detect it and fix it? 🙂
Bert H.
1w
Tried and love neon.
Judy Xiong Adam Soil - a very pertinent conversation on what it means for data being AI ready architecturally!
1️⃣ https://dev.to/rick_houlihan_cf110dba340/lakebase-meet-pdb-the-third-generation-database-oracle-shipped-in-2013-4l8b 2️⃣ https://blogs.oracle.com/database/oracle-ai-database-vs-databricks-lakebase-modern-oltp