Most databases persist data to disk, but the underlying files are usually opaque: binary blobs, internal formats, encrypted pages. You cannot just open a file, edit a few lines, and expect the database state to change.
But using the filesystem itself as the source of truth can be surprisingly powerful.
For my personal blog, I use Hugo. Articles are just Markdown files in a Git repository. In a way, that already behaves like a tiny database: posts have authors, tags, metadata, version history, collaboration via Git.
It is simple and ergonomic.
But once the number of files grows, searching, indexing, querying, and connecting data becomes painful. Filesystems are not databases.
So the obvious question is:
What if the filesystem was backed by a real database?
That is exactly what TigerFS does.
TigerFS is a filesystem backed by PostgreSQL — and also a filesystem interface to PostgreSQL.
Every file becomes a real PostgreSQL row.
Directories become tables.
File contents become columns.
Multiple users can concurrently read and write the same files with full ACID guarantees.
The filesystem becomes the API.
Agent loop is the most important piece of infrastructure in your workflow right now and for most developers, it’s the one piece they can’t open up. Agent builders have to jump through all the hoops themselves, crafting the infrastructure and tools, testing the harness, while fighting to maintain what they’ve built.
Meet Cline SDK: agent harness behind Cline 2.0, fully open-sourced. The same runtime that powers Cline across VS Code, JetBrains, and the CLI is now an npm install away: npm i @cline/sdk. Inspect it, fork it, extend it, ship on it.
Best-in-class harness: 74.2% on Terminal-Bench 2.0 with Claude Opus 4.7 ahead of Claude Code (69.4%) and strongest numbers published on open-weight models.
Open model & provider choice: Anthropic, OpenAI, Google, Bedrock, Mistral, or any OpenAI-compatible endpoint.
Real plugin system: Register tools, hooks, commands, providers, message builders. Prototype as a local file, harden into a package. Extend it freely for any of your agent use cases.
Scheduled + event-driven agents: Cron and event specs for PR reviews, dependency checks, coverage audits, changelogs no separate orchestration layer.
Stop building around your agent. Start building on it.
This model is especially compelling for AI agents.
Agents do not care much about SDKs or dashboards. They love filesystems:
lscatfindgrepshell pipelines
TigerFS lets agents work with ordinary files while getting transactional guarantees from PostgreSQL underneath.
A workflow system can literally become:
Moving files with mv becomes state management.
No extra orchestration layer required.
TigerFS mounts a PostgreSQL database as a filesystem.
On Linux it uses FUSE. On macOS it uses NFS.
TigerFS supports two modes:
You work with normal files:
Markdown
frontmatter
directories
standard UNIX tools
Everything is automatically transactional and versioned.
Editors like Vim, Cursor, Claude Code, or plain shell scripts work out of the box.
You mount an existing PostgreSQL database and explore it like a filesystem:
ls
cat
grep
findTables become directories. Rows become files.
I think one demo is worth more than a thousand words.
Let us build a tiny blog system backed by PostgreSQL, but managed entirely through Markdown files.
On macOS:
Create a database and mount it:
TigerFS apps are configured via a tiny .build directory.
Now create your first article:
Example content:
The YAML frontmatter becomes PostgreSQL columns.
The Markdown body becomes text content.
Now connect directly to PostgreSQL:
Result:
That Markdown file is now a real database row.
And because the filesystem is transactional:
All of those operations become atomic database transactions.
No partial writes. No corrupted state.
TigerFS can also automatically preserve file history.
Enable it like this:
Every modification or deletion becomes a timestamped snapshot stored in a read-only .history/ directory.
It feels a bit like Git — but built directly into the filesystem/database layer.
The obvious use case is content systems:
blogs
catalogs
CMS-like workflows
local editing with remote persistence
But the more interesting angle is probably agents.
Multiple coding agents operating on the same transactional filesystem without stepping on each other is a pretty compelling idea.
Files remain the interface. PostgreSQL handles concurrency and durability underneath.
That combination feels surprisingly natural.
TigerFS sits in a very interesting middle ground between databases and filesystems.
You keep the simplicity and ergonomics of working with files:
But underneath, you get:
PostgreSQL
transactions
concurrency control
structured querying
versioning
The filesystem stops being just storage.
It becomes the API.