Databases pretending to be filesystems.
That’s TigerFS in three words — an experimental open-source project that slaps a PostgreSQL database onto your directory tree. Developers, AI agents: no more wrestling APIs. Just good old Unix commands. ls to list rows, cat to read data, grep to filter. It’s wild, it’s clever, and it’s begging for a closer look at why this architectural flip could stick.
TigerFS arrived quietly, MIT-licensed, from Michael Freedman, CTO at TigerData. He built it to fix a glaring hole: agents crave shared state, but filesystems flake on transactions, databases demand SQL rituals. So he fused them. Mount any Postgres instance — local, cloud, whatever — and boom, your /mnt/tigerfs holds tables as directories, rows as files.
Why Bother Mounting Databases Like This?
Think about your workflow. You’re knee-deep in Claude or Cursor, tweaking AI prompts on Markdown files scattered everywhere. Chaos. TigerFS’s file-first mode organizes them into dirs with atomic writes, auto-versioning. Move a file from /todo to /doing? That’s your task state, concurrent-safe, no locks tripping over each other.
Freedman nails it on LinkedIn:
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.
Data-first flips the script. Got an existing Postgres? Mount it, wander with find, sort paths into queries without typing a single SELECT. Paths encode filters — /users?age>30 sorts and slices on the fly. It’s Unix philosophy on steroids, pipes flowing into ACID waters.
But here’s my take, absent from the hype: this echoes Plan 9’s radical “everything is a file” mantra from the ’90s, but grounded in Postgres’s battle-tested consistency. Back then, Bell Labs dreamed big; now, with AI agents multiplying, TigerFS might actually deliver scalable state for multi-agent swarms — predict agents orchestrating via directory moves, no custom protocols needed.
Short para for emphasis: Performance? That’s the knife-edge.
Hacker News lit up with curiosity, not cheers. iamcalledrob pegs it: small datasets shine, configs and contexts? Perfect. But scale to gigs? FUSE overhead — Linux mount — could drag. macOS NFS sidesteps some pain, yet both lean on Postgres’s row-by-row dance. Each file is a row, yeah, but ls on a million? Query planner sweats.
Freedman admits it’s early:
Every file is a real PostgreSQL row. Multiple agents and humans read and write concurrently with full ACID guarantees. The filesystem /is/ the API (…) I built this mostly for agent workflows, but curious what else people would use it for. It’s early but the core is solid.
Special .dot dirs — .build, .info, .export — sprinkle magic: metadata, query builders, CSV dumps. No external deps beyond FUSE/NFS and Postgres client. Elegant.
How Does TigerFS Dodge the Old Traps?
Rewind to Franck Pachot’s nostalgia: Oracle’s Internet Filesystem (iFS) in 2000 promised this, got hyped to Y2K levels, then fizzled under perf woes and complexity. TigerFS sidesteps with laser focus — Postgres only, no bloat. FUSE keeps it userspace, tweakable. Why now? AI agents exploded; they gulp files, spit chaos without shared truth.
Architecturally, it’s a translator: paths to SQL, writes to INSERT/UPDATE with transactions. Concurrent? Postgres MVCC handles it — readers don’t block writers. Tools like grep? They stream rows as text, filters pushed down. Smart.
Yet skepticism lingers. HN’s bjornroberg loves the primitives, but wonders: real-world perf? Benchmarks missing. My bold call: for agentic workflows under 100k rows, it’s a winner; beyond, pair with materialized views or sharding. Corporate PR spin? None here — Freedman’s solo push feels genuine, not venture-fueled vapor.
Is TigerFS Production-Ready for AI Swarms?
Not yet. Docs scream experimental. FUSE on Linux? Solid for dev, hairy for servers — kernel bypass means context switches galore. macOS NFS? Easier share, but Apple’s walled garden bites. No Windows love, sadly.
Test it: spin Postgres, fuse-overlayfs or whatever, mount. Write a Markdown agent log. Grep patterns across versions. Feels natural — until you hit scale. That’s the shift: forces us to rethink DBs not as silos, but as ubiquitous storage, Unix-style.
Unique angle — this could spark a renaissance in shell scripting for data eng. Imagine awk on exported rows, piped to jq on JSON blobs, all transactional. Agent fleets coordinating via /inbox/outbox dirs? Game on.
Limitations glare: no schema evolution baked in, dot-dirs hacky, perf unproven at scale. But core’s solid, as Freedman says. Fork it, tune it.
One sentence wonder: Agents will eat this up.
And humans too — data explorers ditching SQL for find . -name ‘error’. Bridges worlds.
Franck Pachot geeks out:
I love this - mounting a database as a filesystem. It recalls the excitement of the early Y2K internet era. The idea was so disruptive that the dot in Oracle 8.1 jumped onto the “1” to become an “i”.
Disruptive? Damn right. If it matures, expect forks for MySQL, even BigQuery mounts.
🧬 Related Insights
- Read more: How One Developer Built a Production Pedigree Tree in PostgreSQL—And Why Your Genealogy App Is Probably Broken
- Read more: Google’s Gemma 4 Just Made Expensive AI Models Look Ridiculous
Frequently Asked Questions
What is TigerFS and how do you install it?
TigerFS is an open-source FUSE/NFS filesystem that mounts PostgreSQL databases as directories. Install via Cargo (it’s Rust), connect to your Postgres, mount with fuse or nfsd.
Does TigerFS work with large PostgreSQL databases?
Best for small-to-medium datasets fitting memory; scales via Postgres but FUSE overhead hits big ls/grep ops. Test your workload.
Can AI agents use TigerFS for shared state?
Yes — file moves signal tasks (todo/doing/done), ACID ensures no lost updates in multi-agent setups.
