Baserow

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 database-with-a-grid I actually need instead of a hosted Baserow: typed fields, links between tables, views and an API, over my own data.

Read this first: the product you are replacing is open source, and self-hosting it is a real answer. What you pay for is the hosted instance and real-time collaboration. Build this instead when you need one or two structured datasets with a decent editing surface — not when you need a general spreadsheet platform for a whole company.

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
- tables: id, name, slug, description, created_at
- fields: id, table_id, name, key, kind, position, config_json, is_required, is_unique
- rows: stored in a real table per user table, created and altered by migration, not in a key-value soup. A generic entity-attribute-value store makes every query slow and every constraint impossible
- row_revisions: id, table_id, row_id, field_key, old_value, new_value, actor, at — append-only
- views: id, table_id, kind, name, filters_json, sorts_json, group_by, visible_fields_json, row_height, is_public, public_token
- comments: id, table_id, row_id, author, body, created_at
- attachments: id, table_id, row_id, field_key, path, sha256, bytes, mime

FIELD TYPES, WHICH IS WHERE THE REAL WORK IS
- text, long text, number with precision and an optional currency, checkbox, date with an optional time and a time zone, single select, multi select, email, url, phone, attachment, rating, duration
- link to another table: a real foreign key, one-to-many and many-to-many, with the join table created properly
- lookup: a field from a linked row, read-only, resolved at query time
- rollup: an aggregate over linked rows — sum, count, min, max, average — resolved at query time. Never stored, or it goes stale the moment the linked row changes
- formula: a small expression language over the row's own fields and its rollups, parsed into an AST and evaluated on read, with a dependency graph so a cycle is rejected at save time rather than discovered at render time
- created time, modified time, created by, modified by, and an autonumber that never reuses a value
- Every type has: a parser from typed input, a validator, a formatter for display, a sort comparator, a filter set, and a CSV representation. Write that contract once and implement it per type

VIEWS
- Grid, gallery, kanban grouped by a select field, calendar on a date field, and a form
- Filters composable with and or, per view
- Sorts on several fields, grouping, hidden fields, frozen first column, row height
- A view is a saved question, not a copy of the data
- Public views by token, read-only, with hidden fields genuinely absent from the response rather than hidden in the browser

THE GRID
- Keyboard first: arrows to move, Enter to edit, Escape to cancel, Tab to advance, copy and paste a rectangle including from a spreadsheet
- Virtualised rows so fifty thousand of them scroll
- Undo and redo across edits, backed by the revision log
- Inline validation with the error on the cell, not in a banner

COLLABORATION, HONESTLY
- Optimistic updates with a version per row; a conflicting write is rejected and the newer value shown, rather than silently overwriting
- Live updates by polling a changes-since endpoint on a short interval, which is enough for a handful of people and far less work than a socket layer. Say in the README where that stops being enough
- Comments per row with a mention that sends an email

FORMS
- A view kind: pick fields, set labels and help text, publish at a token URL
- A honeypot and a rate limit per address hash
- Prefill by query parameter, and a redirect or a thank-you message after submission

THE API
- REST per table: list with filters and pagination, get, create, update, delete, all respecting field types and validation
- Tokens with per-table read and write scopes
- Webhooks on row created, updated and deleted, signed and retried with backoff
- CSV import with a mapping step and a dry run that reports what would fail before anything is written

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; a schema change made through the interface writes a migration file
- Nightly backup off the machine, restore script, and an export of every table as CSV in one command
- Health endpoint

WHAT MATTERS MOST
The field type contract and real columns. Build the type system with its six functions per type, then links, lookups and rollups, and only then the grid. Every shortcut taken in the storage layer here becomes impossible to undo once there is data in it.

Give me the repository, migrations, .env.example, a seed base of three linked tables, and a README with deploy steps behind Caddy.