Airtable

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the structured database I actually need instead of Airtable — and know what makes this ALMOST rather than YES.

Two things are genuinely hard here: **real-time multiplayer editing**, which is a distributed-systems problem rather than a feature, and **permissions down to the field level**. If several people edit the same table at the same time all day, you will spend most of the project there. If they mostly do not, this is a fortnight and the result fits your data better than any generic grid.

STACK
- Node 20+ with Fastify, server-rendered HTML with vanilla JS for the grid
- SQLite through better-sqlite3, WAL mode
- No client-side framework
- Caddy in front

THE DATA MODEL
- Real SQL tables per user table, created and altered by generated migrations. Not a generic key-value store: real columns mean real constraints, real indexes and queries that stay fast
- tables, fields, views, and row_revisions (append-only) as the metadata
- Field types: text, long text, number with precision, currency, checkbox, date with optional time and zone, single and multi select, email, url, phone, attachment, rating, duration, and the three that matter — link to another table as a real foreign key, lookup resolved at query time, and rollup as an aggregate over linked rows, never stored
- Formula fields parsed into an AST with a dependency graph, so a cycle is rejected at save time rather than discovered at render
- Each type has a parser, a validator, a formatter, a comparator, a filter set and a CSV form. Write that contract once

COLLABORATION, HONESTLY
- Optimistic writes with a version per row. A conflicting write is rejected and the newer value shown, never silently overwritten
- Live updates by polling a changes-since endpoint every few seconds. That is enough for a handful of people and a fraction of the work of an operational-transform layer
- Write in the README where that stops being enough, and do not pretend otherwise

PERMISSIONS
- Per table, per view, per field, per role, with an optional row predicate
- Enforced inside the query. A hidden field must be absent from the response, not hidden in the browser
- Default deny

VIEWS AND THE GRID
- Grid, gallery, kanban grouped by a select or a link, calendar, and a form
- Filters composable, sorts on several fields, grouping with subtotals, frozen first column, row height
- A view is a saved question, never a copy of the data
- The grid is keyboard-first, virtualised to fifty thousand rows, with copy and paste of a rectangle to and from a real spreadsheet, and undo backed by the revision log

AUTOMATIONS
- Triggers: a row created, updated, or matching a condition; a schedule; a webhook
- Actions: send an email, call an endpoint, write a row, run a small sandboxed script
- Every run recorded with its input and output; retries with backoff; a per-recipient daily mail cap so a loop cannot send four hundred messages

API AND ESCAPE
- REST per table with filtering, pagination, relation expansion, and the same permission code path
- Webhooks on change, signed and retried
- CSV import with a mapping step and a dry run, and export of everything in one command

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Real columns and the field-type contract. Every shortcut in the storage layer becomes impossible to undo once there is data in it, and the link, lookup and rollup trio is where the actual work lives.