The Filesystem Is the API (with TigerFS)
What if the filesystem was backed by a real database?
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.
$ tree
├── about.md
├── an-ode-to-logging.md
├── benchmark-grpc-protobuf-vs-http-json.md
├── books-2025.md
├── building-slack-bot-with-go.md
├── centrally-collecting-events-in-go-microservices.md
├── concurrency-data-race.mdIt 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.
Sponsor
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.
# Install CLI:
npm i -g cline
# Install SDK
npm install @cline/sdkWhy this is interesting
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:
todo/ -> doing/ -> done/Moving files with mv becomes state management.
No extra orchestration layer required.
How TigerFS works
TigerFS mounts a PostgreSQL database as a filesystem.
On Linux it uses FUSE. On macOS it uses NFS.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Unix Tools │────▶│ Filesystem │────▶│ TigerFS │────▶│ PostgreSQL │
│ ls, cat, │ │ Backend │ │ Daemon │ │ Database │
│ echo, rm │◀────│ (FUSE/NFS) │◀────│ │◀────│ │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘TigerFS supports two modes:
File-first
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.
Data-first
You mount an existing PostgreSQL database and explore it like a filesystem:
ls
cat
grep
findTables become directories. Rows become files.
Building a blog with TigerFS
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.
Install
On macOS:
curl -fsSL https://install.tigerfs.io | sh
brew install postgresql@17
brew services start postgresql@17Create a database and mount it:
createdb shinyblog
# long-running process
tigerfs mount postgres://localhost/shinyblog ~/tiger
tigerfs statusInitialize an app
TigerFS apps are configured via a tiny .build directory.
echo "markdown" > ~/tiger/.build/posts
# or enable version history
echo "markdown,history" > ~/tiger/.build/postsNow create your first article:
vim posts/article-one.mdExample content:
---
title: Running MinIO locally with Docker Compose
author: pluto
tags:
- docker
- minio
---
When developing applications that interact with object storage like AWS S3, it’s useful to have a local setup that mimics the real service.
MinIO is an open-source S3-compatible object storage server that fits perfectly for this purpose.The YAML frontmatter becomes PostgreSQL columns.
The Markdown body becomes text content.
Looking inside PostgreSQL
Now connect directly to PostgreSQL:
psql postgres
\c shinyblog
\dt tigerfs.*
\x on
select * from tigerfs.posts;Result:
id | d6ffdc77-87db-4263-a5ad-7e2cacefdcea
filename | article-one.md
filetype | file
title | Running MinIO locally with Docker Compose
author | pluto
headers | {"tags": ["docker", "minio"]}
body | When developing applications that interact with object storage...
encoding | utf8
created_at | 2026-03-29 16:39:43.78583+02
modified_at | 2026-03-29 16:39:43.78583+02That Markdown file is now a real database row.
And because the filesystem is transactional:
cp posts/article-one.md posts/article-two.md
mv posts/article-two.md posts/published.md
rm posts/published.mdAll of those operations become atomic database transactions.
No partial writes. No corrupted state.
Version history
TigerFS can also automatically preserve file history.
Enable it like this:
echo "markdown,history" > ~/tiger/.build/postsEvery 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.
Where this gets interesting
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.
Final thoughts
TigerFS sits in a very interesting middle ground between databases and filesystems.
You keep the simplicity and ergonomics of working with files:
ls
cat
grep
vim
cp
mvBut underneath, you get:
PostgreSQL
transactions
concurrency control
structured querying
versioning
The filesystem stops being just storage.
It becomes the API.