TigerFS: Mount PostgreSQL Databases as a Filesystem for Developers and AI
- Michael Freedman, co-founder and CTO of TigerData, announced the release of TigerFS on April 4, 2026.
- TigerFS enables the use of common Unix tools such as ls, cat, find, and grep to operate on database data, removing the need for traditional APIs, SDKs, or...
- The system functions by mapping database structures directly to filesystem elements.
Michael Freedman, co-founder and CTO of TigerData, announced the release of TigerFS on April 4, 2026. The open-source project introduces an experimental filesystem that mounts a PostgreSQL database as a directory, allowing developers and AI agents to interact with database records through a standard filesystem interface.
TigerFS enables the use of common Unix tools such as ls
, cat
, find
, and grep
to operate on database data, removing the need for traditional APIs, SDKs, or SQL queries for basic data exploration and manipulation.
The system functions by mapping database structures directly to filesystem elements. In this architecture, directories represent tables, individual files represent real PostgreSQL rows, and the contents of those files correspond to database columns.
Because the filesystem is backed by PostgreSQL, TigerFS provides full ACID (Atomicity, Consistency, Isolation, Durability) guarantees. This allows multiple human users and AI agents to read and write to the same files concurrently without the need for separate coordination layers or synchronization protocols.
Operational Modes
TigerFS supports two distinct usage models: file-first and data-first.

The file-first workflow is designed for new projects or workflows where developers organize files, such as Markdown documents, into directories. In this mode, writes are atomic and all files are automatically versioned. This approach allows existing text editors and command-line utilities, including Cursor, Claude Code, and vim, to work with the data without modification.
This mode also enables lightweight application building through the filesystem. For example, multi-agent task coordination can be managed by moving files between directories labeled as todo
, doing
, and done
.
The data-first workflow is intended for existing PostgreSQL databases. It allows users to mount an established database and explore its contents using standard Unix tools. To handle large databases, TigerFS implements a system where filters can be chained into paths, which then push those filters down to SQL.
An example of this path-based filtering is the ability to access specific data via a structured path such as .by/customer_id/123/.order/created_at/.last/10/.export/json
, allowing for precise data retrieval without writing manual SQL queries.
Integration with AI Agents
A primary goal of the project is to provide a shared and reliable state for AI agents. Michael Freedman noted that agents typically perform better with filesystems than with complex APIs.
Agents don’t need fancy APIs or SDKs, they love the file system. Ls, cat, find, grep. Pipelined UNIX tools. So I made files transactional and concurrent by backing them with a real database.
Michael Freedman
By combining the transactional guarantees of a database with the simplicity of a filesystem, TigerFS aims to create a more intuitive environment for agents to coordinate tasks and manage state.
Technical Specifications and Deployment
TigerFS is released under an MIT license. It mounts via FUSE (Filesystem in Userspace) on Linux systems, which requires the installation of fuse3. For macOS users, the system mounts via NFS, requiring no additional dependencies.
Users can initiate a file-first mount by pointing the tool to a PostgreSQL connection string and a mount point. For instance, a database can be mounted to a directory such as /mnt/db
, where the user can then define the structure of a markdown app by echoing configuration into a .build
directory.
While the filesystem interface handles most interactions, the project maintains a SQL escape hatch, allowing users to revert to standard SQL queries when complex operations are required that exceed the capabilities of the filesystem interface.
