Is Your Database Ready for an Army of AI Agents?

Ben Lorica

Mike Freedman and Ajay Kulkarni on Rethinking Postgres, Smarter APIs, and Solving Agent Memory.

Subscribe: Apple • Spotify • Overcast • Pocket Casts • AntennaPod • Podcast Addict • Amazon •  RSS.

Mike Freedman and Ajay Kulkarni, founders of Tiger Data, join the podcast to unveil Agentic Postgres, a database re-imagined for AI agents. They argue that as agents become the new developers, the underlying infrastructure must evolve to support their unique ergonomics — like the need for massive parallelism, safe experimentation sandboxes, and advanced retrieval. The discussion dives deep into their core technical innovations, including a “Fluid Storage” layer that enables instantaneous, zero-copy database forking and an advanced MCP server designed to teach LLMs how to be expert database developers.

Subscribe to the Gradient Flow Newsletter

Interview highlights – key sections from the video version:

Jump to transcript

Related content:

Support our work by subscribing to our newsletter📩

Transcript

Below is a heavily edited excerpt, in Question & Answer format.

The Vision for Agentic Postgres

What is Agentic Postgres and what core problem does it solve?

Agentic Postgres is the first Postgres distribution and cloud service designed specifically around “agent ergonomics”—the assumption that code is increasingly written and operated by AI agents, not just humans. Agents are fundamentally different users than human developers: they don’t click UIs, they call APIs; they don’t naturally “remember” context but excel at retrieval; and they’re massively parallelizable—where one developer worked before, you might now have 10-20 agents working as a multi-threaded team.

This creates new infrastructure demands. Agentic Postgres addresses these by providing: (1) safe, cheap ephemerality through instant, zero-copy database forks for exploration and testing; (2) first-class retrieval with hybrid vector + keyword search for memory and state management; and (3) an MCP (Model-facing Co-Processor) server that teaches coding agents to design schemas, create indexes, tune queries, and operate databases—rather than just exposing a thin API shim.

The changes span from the storage layer up through the developer experience, rethinking the database for a world where agents write a significant portion of cloud code.

Why build on Postgres instead of creating a completely new database for agents?

Operational simplicity and ecosystem gravity. The database industry has a recurring pattern: every new workload (time series, vector search, JSON) spawns purpose-built databases, leaving developers managing seven different systems just to build one application. This operational complexity slows development velocity.

What history has shown over the past decade is that if you can use Postgres, you should use Postgres. When you can extend Postgres to handle new workloads, you get operational simplicity and faster development cycles. PGVector’s success demonstrates this—the market has shown a strong preference for integrated capabilities within Postgres rather than adding another system to the stack.

Moreover, when building production applications, you want proven reliability. The relational model has survived decades through multiple computing paradigms (web, mobile, IoT, blockchain) and will survive agents too. Rather than discarding decades of database innovation and computer science, the better approach is to evolve the proven, reliable platform that developers already trust to meet the new demands of AI agents.

What actually breaks when you point agents at traditional Postgres?

Traditional Postgres wasn’t built for agent ergonomics. Agents don’t click UIs and “remember” like humans—they call APIs, retrieve context at runtime, run many tasks in parallel, and need safe places to experiment and potentially fail. Traditional Postgres doesn’t provide:

  • Instant, isolated sandboxes: No ability to quickly spin up and tear down thousands of ephemeral database instances
  • Elastic, cheap forking: Creating replicas is slow and expensive
  • Agent-aware guardrails: Security models designed for human access patterns
  • Advanced retrieval primitives: Limited full-text search capabilities alongside vector search

The result is unsafe experiments on production, expensive replica management, and brittle development/test loops that don’t match the parallel, experimental nature of agent workflows.

Core Technical Innovations

What is Fluid Storage and why does it matter?

Fluid Storage is Tiger’s proprietary, high-performance network block storage layer designed to replace standard cloud storage like AWS EBS for database workloads. Traditional cloud storage was built for a previous generation and has significant limitations: it scales slowly, charges per allocation rather than usage, and crucially, doesn’t support fast zero-copy forking.

Fluid Storage’s key innovations are:

  • Near-instant snapshots: Roughly 500ms even for terabyte-scale volumes
  • Zero-copy forks: Copy-on-write architecture means creating a fork uses no additional storage initially
  • Elastic scaling: Scales both up and down rapidly
  • Consumption-based billing: You only pay for the differences (deltas) between forks, not duplicate storage
  • Standard protocols: Speaks standard network block device protocols, so it works with any container just like EBS

Practically, you can snapshot your entire production database and create thousands of isolated forks for agents to work in parallel. Each fork appears as a fully isolated, writable volume but shares underlying storage. New storage is only consumed for writes that differ from the original. This makes it incredibly efficient to spin up and tear down thousands of ephemeral database instances for parallel agent tasks, testing, or analytics—something that is prohibitively slow and expensive with traditional infrastructure.

Can you really scale to thousands of isolated agent databases?

Yes, that’s a core capability enabled by the zero-copy fork mechanism. You can spin up thousands of database instances nearly instantaneously, each isolated but sharing underlying storage through copy-on-write.

This is critical for agentic workflows where you might want to:

  • Give multiple agents isolated sandboxes to explore solutions in parallel
  • Test different indexing strategies against production-scale data
  • Let agents experiment with schema changes without risk
  • Provide each agent task with its own database instance

The architecture is designed specifically for the scale and ephemerality that agent workloads demand. You only pay for the deltas, making parallel agent teams affordable.

Your MCP server is described as more than just an API. What makes it special?

Most MCP servers are just thin shims that expose an existing API to a model—essentially REST or GraphQL translated to the MCP protocol. They give agents access to call functions like creating databases or running queries.

Tiger’s MCP server goes much further by actively teaching Claude how to be a better database developer. Instead of requiring expensive fine-tuning, it uses the MCP server to inject decades of domain-specific knowledge about Postgres at runtime. It incorporates the team’s knowledge about building and running Postgres at scale through prompt templates/”skills” and retrieval over Postgres and Tiger documentation.

When an agent builds an application, the MCP server:

  • Analyzes proposed schemas and returns contextual optimization suggestions
  • Guides agents on data modeling best practices
  • Suggests appropriate indexes for query patterns
  • Provides context-aware guidance on query optimization
  • Helps agents infer and normalize schemas
  • Orchestrates forks for A/B testing different designs

It’s providing a domain-specific “skills layer” that makes general-purpose coding models like Claude much more effective at database work, allowing them to perform like specialists without needing to be retrained.

What specific database features did you build or enhance for agents?

Several key areas were addressed:

  1. Full-text search: Implemented BM25 full-text search in a new Postgres extension (pg_text_search), enabling modern search capabilities alongside vector search.
  2. Hybrid search: You can combine vector and keyword search with hybrid re-ranking directly in Postgres, getting the benefits of both semantic and exact-match search without multiple systems.
  3. Vector search optimization: Built VectorScale on top of PGVector, which shows significant performance advantages at scale (tens of millions of vectors and up). While PGVector is good for many use cases, VectorScale handles high-cardinality, vector-heavy workloads.
  4. Forkable databases: Fast zero-copy forks built on Fluid Storage, enabling agents to safely experiment with production-scale data.
  5. Enhanced instrumentation: Kernel-level statistics collection providing per-query information (execution plans, memory usage, buffer usage, timings), enabling agents to understand and optimize database performance.

State and Memory Management

How does Agentic Postgres address agent state and memory management?

Tiger’s view is that the database is the ideal place to manage all agent state and memory. An agentic architecture has three main pillars: the agent code (control plane), the LLM it calls, and the database. All persistent information should reside in the database rather than scattered across specialized systems:

  • Application state
  • Conversation history
  • Durable execution checkpoints
  • Long-term memory
  • Traces and reasoning steps

Why will databases win out over specialized memory layers for agents?

History repeats itself. Just like with time series, vector search, and other workloads, people initially build specialized systems. But operational simplicity matters—you don’t want sprawl across a dozen state management systems for one application.

Many new “memory layer” startups are discovering they’re really building structured retrieval and state management—problems databases already solve. Memory in agents is fundamentally a structured retrieval problem. Initially, simple key-value storage works, but as memory grows, you blow out context windows and need selective retrieval. Memory becomes a prioritized search problem.

How does search relate to agent memory?

The two pillars of AI search—advanced vector search and keyword search (BM25)—provide the building blocks for memory. Combined with hybrid re-ranking in Postgres, you have sophisticated retrieval without adding separate memory-specific systems.

Beyond search, effective memory needs to be:

  • Transparent and mutable: You should be able to inspect, update, or delete memories. Storing them in a database makes CRUD operations natural and enumerable.
  • Scoped appropriately: Some memories are individual, others shared across groups. Database access controls and security scopes handle this naturally.
  • Synthesizable: Raw traces can be summarized by LLMs and stored as refined memories, creating a learning loop.

Graph representations and knowledge ontologies that some memory systems build can be represented as relations in tables rather than requiring specialized graph databases.

How do you handle durable execution and multi-step agent workflows?

Popular durable execution frameworks for agents (handling chain-of-thought and multi-step processes) already typically use Postgres underneath. The control plane of agents—tracking steps A to B to C, recovering from failures—is already being stored in Postgres by these frameworks.

This extends to Tiger’s internal tooling where Postgres serves as a lightweight queuing system for agent tasks. Reasoning steps from models can be captured and stored in Postgres for diagnosis when things go wrong. The database naturally becomes the durable substrate for agent execution, not a separate layer.

Practical Applications and Workflows

How does forkable storage change the development workflow for teams using AI agents?

It enables a Git-like branching workflow for your data. The development workflow fundamentally shifts—developers with AI coding assistants effectively become engineering managers, leading a team of agents.

In practice with tools like Claude, you might:

  1. Describe an application you want to build
  2. Claude analyzes requirements and designs a schema using the MCP server’s guidance
  3. You tell Claude to spin up a fork and test the implementation
  4. Claude iterates in the fork, getting feedback from actual query results
  5. Once satisfied, you merge changes back to your main database

For production debugging or optimization, a developer can instruct an agent to tackle a task, like optimizing a slow query. The agent can:

  1. Instantly create multiple forks of the production database
  2. Test different indexing strategies in parallel on each fork, using full production-scale data
  3. Analyze the results and report back on which strategy was most effective
  4. The developer reviews the agent’s proposed code (e.g., the CREATE INDEX statement) and merges it into the production branch

This allows agents to safely “cook”—to experiment, iterate, and even fail—in an isolated sandbox without any risk to the live production system. It provides a feedback loop where the agent gets real performance data from its experiments.

How does this work with existing codebases and schemas?

Through the MCP server’s prompt templates/”skills” functionality, agents can introspect existing schemas and get guidance on working with them. The MCP server analyzes your schema and injects relevant knowledge about optimization, best practices, and Postgres-specific considerations.

For operational databases specifically, you’re typically pointing agents at specific databases rather than having them discover across thousands of tables (unlike analytics scenarios with sprawling data lakes). This is simpler and more focused. Context can also be specified in Claude MD rules or similar configuration files.

Can this forkable architecture also be used for analytics?

Yes, it’s a very compelling analytics use case. There’s an important insight here: for most companies, especially startups, the first data warehouse is just a replica of their production Postgres database. Teams often end up with multiple analytics replicas because queries interfere with each other.

Instead of managing slow, lagging replicas and worrying about analysts or agents running heavy queries that impact others, you can instantly fork the production database. This gives the analytics team, BI team, product team, or any agent an up-to-the-minute, isolated copy to run any query or schema change they want without affecting anyone. Once they’re done, the fork can be deleted.

This is particularly relevant because agents need to analyze data frequently, and the traditional warehouse/database distinction blurs when you can fork production instantly. For the majority of companies whose “data warehouse” is really just replicated Postgres, this approach eliminates the replica tax and operational overhead.

How does this compare to lightweight approaches like SQLite or DuckDB for agents?

There are applications where ephemeral, file-based databases make sense for short-lived, on-device tasks. However, when building real production applications—not just quick experiments—you need:

  • Proven reliability and maturity
  • Access controls and security
  • Scalability beyond single files
  • Transaction support
  • The full ecosystem of tools and extensions

Postgres provides all this plus the ability to start small and scale. Even with agents, when you’re building production applications, these fundamentals matter. The innovation is making Postgres work better for agentic workflows, not replacing it with something more minimal.

The focus of Agentic Postgres is primarily on cloud-based development and production workloads—targeting startups, hobby projects, and new enterprise workloads—rather than edge deployments.

Infrastructure and Guardrails

Can agents provision databases on demand? What guardrails are in place?

Yes, through the MCP server and CLI, agents can provision and manage databases. Critical guardrails include:

  • Rate limiting: Standard protections against runaway resource consumption
  • Token-based authentication: Proper security controls
  • Access controls: Read-only vs. read-write permissions, with fine-grained scoping
  • Partial masking: Ability to give agents access to subsets of data (column/row masking)
  • Fork-first principle: Rather than putting heavy guardrails around production access, give agents forks to experiment with

The primary guardrail is the concept of forkability itself. The best practice and safest pattern is not to give agents a “long leash” with direct access to the production database. Instead, you give them a fork to work in—full write access inside an isolated fork, then review results and merge. This philosophy of “let your agents cook, but in a safe way” preserves velocity while bounding risk.

Do you need a separate vector database, or does Agentic Postgres handle unstructured and vector data?

You do not need a separate vector database. The market has shown a strong preference for integrated vector capabilities within Postgres, as evidenced by PGVector’s popularity. Agentic Postgres builds on this foundation:

  • PGVector: For embeddings and general vector search use cases
  • VectorScale: An open-source extension built on top of PGVector for high-cardinality, vector-heavy workloads (tens of millions of vectors and up) that requires additional scale
  • BM25 full-text search: The new pg_text_search extension for modern keyword search
  • Hybrid search: Combine vector and keyword search with re-ranking directly in-database

This allows for sophisticated hybrid search and re-ranking to be performed directly in the database, providing the core building blocks for agent memory and retrieval-augmented generation (RAG) without adding another system to your stack. While Postgres is primarily an operational database, it handles semi-structured data like JSON extremely well through native JSONB support.

What about semantic layers? Do operational databases need them like warehouses do?

The semantic layer concept is really about providing more relevant context to agents. In operational databases, this looks different than in warehouses because:

  • You’re not doing text-to-SQL across thousands of tables simultaneously
  • You’re typically exploring smaller, focused subsets
  • Context can be injected through MCP prompt templates rather than separate layers
  • The database can expose semantics (schema, constraints, domain hints) directly

The MCP server effectively provides semantic understanding by teaching models about your schema, constraints, and optimization opportunities in real-time. This is a simpler and safer model than global warehouse semantics for many application teams. For operational use, you typically point agents at specific databases or forks (smaller scope than “entire lakehouse”).

Operational Considerations

What about observability and SRE for databases in an agent-run world?

Tiger instruments at a low level, collecting kernel-level statistics about queries—execution plans, memory usage, buffer usage, timings, and detailed per-query information. While humans struggle to use this data effectively (it requires deep database expertise), agents can leverage it directly.

The vision is making agents expert at both building applications and operating databases. Initial MCP work focused on development capabilities, but the instrumentation enables agents to become database SREs—understanding performance, detecting regressions, suggesting optimizations, recommending indexes, rewriting slow queries, and potentially replacing traditional runbooks.

When durable execution stores control-plane state in Postgres, you can also store reasoning steps and traces for auditability and postmortems when things go wrong. Traces and logs become inputs to a learning loop—collected, synthesized by LLMs, and stored as refined knowledge in the database.

Which Postgres extensions should AI app teams know about?

Key extensions for building AI applications:

  • TimescaleDB: For time series data and observability use cases (open source)
  • PGVector: For embeddings and vector search (open source)
  • VectorScale: For high-scale vector search atop PGVector (open source)
  • JSONB: Native semi-structured data support built into Postgres
  • pg_text_search: Tiger’s BM25 full-text extension for modern keyword search

For multimodal data (images, audio, video), Postgres can handle storage and types via extensions, while your model does the interpretation.

Ecosystem and Future Directions

What other parts of the software stack need to be reinvented for agents?

The perspective is that probably nearly every part of the stack will need some evolution, though the degree varies:

  • IDEs: Already becoming agent-native (e.g., Cursor, GitHub Copilot)
  • Headless browsers: Being developed specifically for agent interaction
  • Documentation: Moving from static pages to interactive, searchable knowledge bases that agents can query effectively—semantic and full-text search plus prompt templates show the direction
  • Caching: Traditional exact-match caching is insufficient. The future is semantic or “approximate” caching, where the system can return a cached result for a “close enough” query. This is ill-defined and requires interesting technical work—an area of active research.
  • Database tooling: Tools built for humans (query builders, schema designers, monitoring dashboards) need agent-native versions focused on programmatic access and machine interpretation
  • Observability & SRE: Runbooks and operations will be radically transformed as agents take on more SRE tasks, using low-level instrumentation data to diagnose and fix issues automatically, with a human in the loop

Database-specific workflows are also evolving—the traditional staging/production model gives way to branch-per-experiment workflows more like modern software development.

Is there a flywheel effect where agents learn from each other’s database interactions?

This is an emerging area. Currently:

  • LLMs appear to have some cross-session memory (whether from the provider’s side or the API)
  • You can explicitly create memory stored in the database for knowledge sharing between agents
  • Most teams are still at the stage of just getting agents working, not optimizing inter-agent learning

The infrastructure for this is being built—storing traces, synthesizing learnings, enabling retrieval across agent interactions—but the market is early. The foundation that Tiger provides is that all state, all memory, resides in the database, which makes future innovations in this area straightforward to implement.

Open Source and Availability

What’s open source today, and what isn’t?

Tiger remains committed to open source:

  • TimescaleDB: Open source
  • VectorScale: Open source
  • Eon (Tiger Agents for Work): Open source—an internal Slack-centric agent that demonstrates these patterns

Currently available via Tiger’s cloud but not open source:

  • Fluid Storage: The block storage layer involves many layers and doesn’t package as a standalone project easily
  • pg_text_search: The BM25 extension is implemented as a Postgres extension but currently available only via Tiger’s cloud. The decision on whether to open source it hasn’t been finalized.

The philosophy balances open source community benefits with the operational complexity of some infrastructure components.

What are the free-tier limits if we want to experiment?

At launch, the free tier includes:

  • Two services
  • Up to ~750 MB of data per service
  • Forking enabled
  • Insights and metrics
  • 24-hour point-in-time recovery
  • Full managed features with size/count limits
  • CLI can bring a service up in one command

You get many of the managed features with limits appropriate for experimentation, and the architecture is built to be cost-effective through efficient, ephemeral infrastructure.

How do I interact with Fluid Storage if it’s not open source?

As a standard network block device—similar to attaching EBS to a container. You don’t need a custom file format or special drivers. Any Postgres service Tiger hosts sits on top of this block layer transparently. Other products can potentially integrate with it via standard block-device protocols in the future.