A Database Built for Software That Writes Itself
Tiger Data, the New York company that spent a decade as Timescale building a time-series extension for Postgres, has made a managed database service aimed squarely at AI agents generally available. The pitch starts from a provocation: conventional database architectures assume a human operator who provisions carefully and cleans up afterward, and that assumption breaks when the operator is an autonomous agent generating and discarding work at machine speed. The company argues the future of software is being built and run by coding agents, and that those agents need infrastructure designed for relentless, large-scale experimentation rather than for human caution.
Chief executive Ajay Kulkarni frames the shift in stark terms. The idea, he says, is that all new applications are being built with coding agents, and we believe the agent is the future packaging of software. That belief drives a different economic model for the database itself. Databases are free, Kulkarni argues, you could have one database per agent or one database per task. In a world where spinning up a fresh, isolated environment costs almost nothing, the database stops being a scarce, carefully shared resource and becomes something closer to a scratch pad.
Forking Production in Seconds
The technical centerpiece is a new copy-on-write block storage layer the company calls Fluid Storage, which makes databases instantly forkable. Every agent can spin up its own isolated environment, a full copy of production data in seconds, without duplicating the data or the cost. For an agent testing a schema change, debugging a failing migration or trying three different approaches in parallel, that means each attempt runs against a real copy of the workload instead of a stale fixture, and the failed branches can be thrown away as cheaply as they were created.
Around that forking core, the service layers the features an agent needs to act. It ships with an MCP server so agents can connect through the protocol that has become the lingua franca of tool use, native BM25 keyword search and vector search for retrieval workloads, and a command line interface for terminal-driven access. Crucially, billing is based on active compute usage rather than per-database licensing, which is what makes the one-database-per-task model financially sane. You cannot encourage thousands of disposable databases and then charge a license fee for each one.
Why Postgres, and Why Now
The choice of Postgres is not incidental. Over the past few years Postgres has become the default substrate for AI applications, in part because its extension ecosystem lets a single engine handle relational data, vector embeddings, geospatial queries and time series without forcing teams to operate a separate specialized store for each. Tiger Data leans into that lineage, keeping compatibility with TimescaleDB, pgvector and PostGIS so existing workloads carry over. Kulkarni is blunt about where he thinks this lands: I would be surprised if the database for agents is not Postgres.
The timing reflects how quickly the center of gravity in software development has moved. A company founded ten years ago to make Postgres better at storing sensor data, with around 200 employees across 25 countries and more than 3,000 customers, has rebranded and rebuilt its story around agents in the span of a year. That is a significant strategic wager for a firm of its size, and it is being made on the conviction that the volume of database operations driven by agents will dwarf what human developers ever generated.
What It Means for Data Teams
For data and platform teams, the most useful idea here is not the branding but the operational pattern. Instant, cheap forks of production data change how you think about testing and change management. Today a risky migration is rehearsed against a sampled copy or a staging environment that drifts out of sync with production. If forking a true copy takes seconds and costs only the compute it consumes, the rehearsal can happen against real data on every change, and the cost of being wrong drops sharply. That is valuable whether the actor running the migration is an agent or a human.
The caution we would add is governance. A model that encourages thousands of ephemeral databases, each potentially a full copy of production data, is a model that can scatter sensitive records across short-lived environments faster than most data-loss and access-control tooling can track. The same copy-on-write magic that makes experimentation cheap also makes data sprawl cheap. Teams adopting agent-native databases will need lineage, retention and access policies that assume the database population is fluid, not fixed, or the convenience will outrun the controls.
A Crowded Race for the Agent's Backend
Tiger Data is not alone in seeing Postgres as the agent's natural home. Neon built its business on serverless Postgres with branching, Supabase has ridden the vibe-coding wave to a multibillion-dollar valuation, and every hyperscaler now offers a managed Postgres with vector search bolted on. What differentiates this launch is the explicit framing of the agent, rather than the developer, as the primary user, and the storage architecture built to make per-task databases economical. The competitive question is whether forking speed and an MCP-first design are enough to win in a market where Postgres compatibility is table stakes.
Our read is that the agent-native database is a real category rather than a marketing label, because the access pattern genuinely differs from human-driven development. Whether Tiger Data captures it depends less on the elegance of Fluid Storage and more on trust: enterprises will hand agents disposable copies of production data only if the platform makes governance, isolation and cost predictable. The company has made a clear bet on where software is heading. The next year will show whether buyers are ready to provision databases the way agents want to consume them.
