In a recent piece, I explored the growing mismatch between our existing data infrastructure and the demands of emerging AI agents. Since then, I have had the opportunity to speak with some founders and engineering leaders who are tackling this challenge directly. Their work confirms that the rise of agentic AI is not just an application-layer phenomenon; it is forcing a fundamental reconsideration of the database itself. This article examines four distinct initiatives that are reimagining what a database should be in an era where software, not just humans, will be its primary user.
Regular reader? Consider becoming a paid supporter
AgentDB: The Database as a Disposable File
AgentDB reimagines the database by treating it not as persistent, heavy infrastructure but as a lightweight, disposable artifact, akin to a file. Its core premise is that creating a database should be as simple as generating a unique ID; doing so instantly provisions a new, isolated database. This serverless approach, which can utilize embedded engines like SQLite and DuckDB, is designed for the high-velocity, ephemeral needs of agentic workflows, where an agent might spin up a database for a single task and discard it upon completion.
The initiative assumes that a significant portion of agentic tasks do not require the complexity of a traditional relational database. Its target use cases include developers building simple AI applications, agents needing a temporary “scratchpad” to process information, or even non-technical users who want to turn a data file, like a CSV of personal expenses, into an interactive chat application. Its primary limitation is that it is not designed for complex, high-throughput transactional systems with thousands of interconnected tables, such as an enterprise resource planning (ERP) system. AgentDB is currently live and accessible, with a focus on empowering developers to quickly integrate data persistence into their AI applications with minimal friction.
Postgres for Agents: Evolving a Classic for AI
Tiger Data’s “Postgres for Agents” takes an evolutionary, rather than revolutionary, approach. Instead of building a new database from scratch, it enhances PostgreSQL, the popular open-source database, with capabilities tailored for agents. The cornerstone of this initiative is a new storage layer that enables “zero-copy forking.” This allows a developer or an agent to create an instantaneous, isolated branch of a production database. This fork can be used as a safe sandbox to test schema changes, run experiments, or validate new code without impacting the live system.
This approach is built on the assumption that the reliability, maturity, and rich ecosystem of Postgres are too valuable to discard. The target user is any developer building applications with AI, who can now instruct an AI coding assistant to safely test database migrations on a full-scale copy of production data. It also serves AI applications that require a robust and stateful backend. The platform is now available via Tiger Data’s cloud service, which includes a free tier. While the core forking technology is currently proprietary, the company is signaling a long-term commitment to the open Postgres ecosystem.
Databricks Lakebase: Unifying Transactions and Analytics
The Databricks Lakebase represents a broad architectural vision aimed at dissolving the long-standing wall between operational and analytical data systems. It proposes a new category of database — a “lakebase” — that embeds transactional capabilities directly within a data lakehouse architecture. Built on open standards like Postgres, it is designed to be serverless, separate storage from compute for elastic scaling, and support modern developer workflows like instantaneous branching.
The core assumption of the Lakebase is that intelligent agents require seamless access to both real-time operational data and historical analytical insights to perform complex tasks. For example, an inventory management agent needs to check current stock levels (a transactional query) while also considering predictive demand models (an analytical query). The Lakebase is targeted at organizations, particularly those already invested in a lakehouse architecture, that want to build AI-native applications without the cost and complexity of maintaining separate databases and data pipelines. This is currently a strategic roadmap for Databricks, accelerated by its recent acquisition of companies like Mooncake Labs, and represents a long-term effort to create a single, unified platform for all data workloads.
Bauplan Labs: A Safety-First Approach for Agents
Bauplan Labs approaches the problem from the perspective of safety and reliability, motivated by the principle that modern data engineering requires the same rigor as software engineering. Their work focuses on creating a “programmable lakehouse,” an environment where every data operation is managed through code-based abstractions. This provides a secure and auditable foundation for AI agents to perform sensitive tasks. The central concept is a rigorously defined “Git-for-data” model, which allows agents to work on isolated branches of production data. Crucially, it introduces a “verify-then-merge” workflow. Before an agent’s changes are integrated, they must pass a series of automated correctness checks.
This framework assumes that for agents to be trusted with mission-critical systems, their actions must be verifiable and their potential for error contained. The target use cases are high-stakes scenarios, such as an agent tasked with repairing a broken data pipeline or safely querying financial data through a controlled API, where a mistake could have significant consequences. Bauplan is building its platform on a formal blueprint for safe, agent-driven data systems, an approach already being validated by early customers. While the company offers open-source tooling on GitHub, its focus is on providing a commercial-grade framework for high-stakes, agent-driven applications that will influence the design of future platforms.
These four initiatives, from AgentDB’s file-like simplicity to the ambitious unification of the Databricks Lakebase, highlight a clear trend: databases are being reshaped to serve machines. Whether by evolving the trusted foundation of Postgres or by designing safety-first frameworks like Bauplan’s, the data community is moving toward systems that are more ephemeral, isolated, and context-aware. As outlined in my earlier thoughts, databases are becoming more than just repositories of information; they are the operational state stores and external memory that provide agents with the traceability, determinism, and auditable history needed to function reliably.
Of course, the database is just one piece of the puzzle. As agents become more integrated into our workflows, other components of the technology stack also require reimagination. Search APIs, traditionally designed to return ten blue links for a human, must be adapted to deliver comprehensive, structured information for a machine. Development environments and IDEs are already evolving to become collaborative spaces for humans and AI coding assistants. The entire infrastructure, from headless browsers that allow agents to interact with the web to the observability tools that monitor their behavior, is being rebuilt for an agent-native world.
