Data-first mode. Mount any database, query it as files.

browse your database
with ls and cat.

Mount any PostgreSQL database as a directory and explore it with ls, cat, and grep. Tables are folders, rows are files, columns are fields: the interface your agents already know, mapped onto your data. Compose filters, ordering, and pagination into one path, and the whole query pushes down to a single SQL statement, so even huge tables stay fast. Same engine as file-first, with a SQL escape hatch when you want it.

Get started Read the docs
The basics

your database as a directory

Mounting a database turns every table into a directory and every row into a file. List with ls, read with cat, search with grep. Before you touch a table, inspect its columns and size through .info/. No SQL, no client, no schema to memorize.

# mount any Postgres database tigerfs mount postgres://localhost/shop /mnt # tables are directories; rows are files ls /mnt/ cat /mnt/users/123.json # inspect a table before you query it cat /mnt/orders/.info/columns cat /mnt/orders/.info/count

Every path is just a query. Reading one row runs one small query; for big tables, you push the work down into the database with pipeline paths, which is next.

Killer feature

pipeline queries

Chain filters, ordering, and pagination into a single path. The database executes it as one optimized query. Only matching rows ever cross the wire.

The last 10 orders for customer 123, newest first, as JSON, is a directory path:

cat /mnt/orders/.by/customer_id/123/.order/created_at/.last/10/.export/json

Segments compose in any order:

No SQL client, no schema in your head, no N+1 filesystem calls. Just one path, one query.

What you can build

work directly with live data

Quick data fixes

Update a customer's email, toggle a feature flag, delete a test record. One shell command does it, with no SQL client and no carefully crafted WHERE clause.

# update a single column echo '[email protected]' > /mnt/users/123/email.txt # PATCH a full row via JSON (only listed keys change) echo '{"email":"[email protected]","name":"A"}' > /mnt/users/123.json # delete a record rm -r /mnt/users/456/

Data analytics

Standard Unix tools work on every table. For larger questions, push the filtering into the database and let awk finish the job.

# sum shipped order totals — filter runs in Postgres cat /mnt/orders/.filter/status/shipped/.columns/total/.export/csv \ | awk '{s+=$1} END {print s}'
With an agent

you ask, the agent navigates

You don't write paths by hand. The agent reads the schema as files, builds the pipeline path, and asks before it writes. A few exchanges:

You
I'm new to this database. What's in the orders table?
Agent
Reading /mnt/orders/.info/columns, .info/count, and a sample of 5 rows…

Shape: 47,283 rows, 8 columns. Indexed on customer_id, status, created_at.

Columns: id (uuid PK), customer_id, status (pending/shipped/delivered/cancelled), total, created_at / shipped_at, payment_method, currency.

Recent activity: mostly shipped, card payments, totals under $200.
Want me to drill into a customer, date range, or status?

Under the hood: the metadata dot-directories expose the database's own catalog as files: .info/columns, .info/count, .info/schema, index lists, and a .sample/. Reading those lets the agent reason about a table before it touches anything, instead of blindly ls/cat-ing millions of rows.

The skills teach the rules: check .info/count first, sample before scanning, and look up by an index when you can.

You
What are the 10 biggest shipped orders?
Agent
One pipeline path does it: filter to shipped, order by total, take the highest 10, as JSON. The database runs it as a single query, so nothing else crosses the wire.

cat /mnt/orders/.filter/status/shipped/.order/total/.last/10/.export/json

Top one is order 8842 at $1,240.
Group these by customer, or export to CSV?

Under the hood: TigerFS's dot-directories compose like a pipeline: .filter/status/shipped, .order/total, and .last/10 chain into one path that runs as a single SQL query, so only ten rows cross the wire.

You could cat the rows and grep/sort them yourself, but composing the query pushes the work into the database, which is what keeps it fast on large tables.

You
Find customer [email protected] and bump her tier to premium
Agent
Reading /mnt/customers/.by/email/[email protected]…

Found: customer 4172 (Alice Chen), signed up 2025-11-04, current tier: standard.

Planned update: write premium to /mnt/customers/4172/tier. Other fields untouched (PATCH-style).
Apply?

Under the hood: it resolves the row by an indexed lookup (cat .by/email/[email protected]), then writes one field (echo 'premium' > customers/4172/tier), a PATCH that leaves every other column untouched.

It confirms first, because data-first writes are permanent.

Note: data-first writes are direct and permanent. For reversible writes, use a file-first workspace with history enabled.

Formats & navigation

every row, every shape

Read a row in whatever format fits the task — .json for jq, .yaml for hand-editing, .csv for spreadsheets — or navigate into a row to treat its columns as individual files.

# the same row, different formats cat /mnt/users/123.json cat /mnt/users/123.yaml # a row as a directory of columns ls /mnt/users/123/ cat /mnt/users/123/email.txt

File-first workspaces have backing tables too. Reach them data-first under /mnt/.tables/<workspace>/ for column-level queries, but note that writes through .tables/ bypass the history trigger, so they don't appear in .log/ or undo. Use them for diagnostics, not day-to-day edits.

Why data-first

versus the alternatives

The usual ways into a database make agents pay a tax on every task: a client, a schema to remember, libraries to pass around, or an export step before any tool can touch the data.

Capability TigerFS SQL client ORM CSV export
No SQL to write✓✗~✓
Works with Unix tools (grep/cat/awk)✓✗✗✓
No client libs / schema memorization✓✗✗✓
Query pushdown to the database✓✓✓✗
Live data, no export step✓✓✓✗
PATCH updates (touch only changed fields)✓~✓✗
Look up by any indexed column✓✓✓✗

TigerFS is the only one of these that's both as easy as files and pushes real queries into the database.

point it at your database.

Install in under 60 seconds and mount any PostgreSQL as a filesystem.

Get started Read the data-first docs