Excel to database — keep the spreadsheet, lose the file.

Moving a spreadsheet into a database usually means losing the people who lived in it. Here's the version where your team keeps their table, their formulas, and their views — and the file rituals stop.

Four signs your spreadsheet has outgrown Excel

The Monday merge ritualEvery week someone VLOOKUPs sheet A into sheet B, fixes the #N/A fallout, and emails the result. The same join, by hand, forever.
The file takes minutes to openHundreds of thousands of rows; recalculation crawls; someone suggests splitting it by month, which makes everything else worse.
final_v3_REAL.xlsxCopies in chat threads, copies in email, copies per quarter. Nobody knows which one is true anymore.
People watch it by asking for exportsScreenshots and re-attached files stand in for "can I just see the current numbers?"

What moving out actually looks like

With a coding agent (Claude Code, Codex, Cursor) driving tabledi, the migration is a conversation, not a project:

# the sources come in once — files or a published-CSV link a channel keeps polling tabledi import ops-costs.xlsx --new "Costs" tabledi import revenue.csv --new "Revenue" # the Monday ritual becomes a derived table: joined, grouped, always current # and questions become deterministic queries — same answer, every time, gen-stamped tabledi query '{ "source": "daily_pnl", "group": [...] }'

Columns are typed on import. Your formulas survive — VLOOKUP, XLOOKUP, SUMIF and 60+ others are built in with spreadsheet semantics. The engine is columnar and holds millions of rows; aggregates that froze Excel come back in milliseconds.

Why not just "use a real database"?

Because Postgres solves the size problem and creates a people problem: the ops teammate who owned that spreadsheet can't open psql. tabledi keeps both sides of the handoff working — your agent gets a CLI, an MCP server, and deterministic, audited writes; your teammates get invited into the workspace and see the same tables and views, updating live, formulas intact. No exports, no stale screenshots — and no one has to learn SQL to check a number.

One-way door, on purpose: files are the entrance (CSV/XLSX import, published-CSV channels, JDBC/Mongo). The exit is a living table — queries, views, change feeds — plus raw CSV/XLSX export as an escape hatch. tabledi does not render report documents; if your job's end state is a formatted file, in-place tools are the right home for it.

Trust, since an agent is doing the writing

Every write is validated against the column types, optimistic-locked, rate-limited and audited. Every query answer carries a generation stamp — ask the same question a hundred times and you get the same number a hundred times. And the whole thing is a single Rust binary you can self-host, so "move it out of Excel" never has to mean "move it out of the building".

Give your spreadsheet a backend.

Install the CLI, hand it to your agent, point it at the file.

Get started See what it does