NocoDB

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 spreadsheet interface I actually need instead of a hosted NocoDB: grid, kanban and form views over the database I already have, without moving the data.

Read this first: NocoDB is open source and self-hosting it is a real answer — the fee buys hosting and the team features. Build this when the schema is yours and stable, because a generated interface over ten known tables fits your data better than a generic one, and the grid is the only genuinely hard part.

STACK
- Node 20+ with Fastify, server-rendered HTML with vanilla JS for the grid
- Your existing Postgres or MySQL through its own driver; SQLite through better-sqlite3 for this tool's own state
- No client-side framework
- Caddy in front

THE DATA MODEL, MEANING THIS TOOL'S OWN
- tables: id, schema_name, table_name, label, primary_display_column, is_hidden
- columns: id, table_id, column_name, label, kind, interface, options_json, position, is_readonly, hidden_in_list
- relations: id, from_table, from_column, to_table, kind, join_table — read from the foreign keys, overridable
- views: id, table_id, kind, name, filters_json, sorts_json, group_by, visible_columns_json, row_height, is_public, public_token
- roles, permissions: role_id, table, action, columns_json, row_filter — enforced at the query layer
- audit: id, actor_id, action, table, row_pk, before_json, after_json, at — append-only
- The tool stores configuration only. The data stays where it is, which is the entire proposition

INTROSPECTION
- Read the schema: tables, columns, types, nullability, defaults, primary keys, foreign keys, unique and check constraints, enums
- Map each column type to a default interface, and store every override. Guessing is a starting point, not an answer
- Detect a schema change on boot and report it rather than adapting silently
- Never alter the source schema unless explicitly asked, and when asked, write a migration file rather than running DDL from a click

THE GRID, WHICH IS THE HARD PART
- Virtualised rows and columns, so a hundred thousand rows scroll without stutter
- Keyboard first: arrows to move, Enter to edit, Escape to cancel, Tab to advance, Shift-arrow to select a range, copy and paste a rectangle including to and from a real spreadsheet
- Frozen first column, resizable columns, adjustable row height, and column order per view
- Inline editing with the type's own editor, validated against the database's own constraints before the write
- Undo and redo, backed by the audit log
- Filters composable with and or, sorts on several columns, grouping with counts and subtotals
- Search within the view
- This is far more work than it looks. Budget most of the project for it, and do not start it until the query layer is right

VIEWS
- Grid, gallery, kanban grouped by an enum or a foreign key, calendar on a date column, and a form
- A view is a saved question, never a copy of the data
- Public views by token, read-only, with hidden columns genuinely absent from the response

FORMS
- Pick columns, set labels and help text, publish at a token URL
- Server-side validation against the real constraints, a honeypot and a rate limit
- Insert into the real table, respecting defaults and nullability

RELATIONS
- A foreign key renders as a picker with search over the target's display column
- The related rows shown inline on a record, expandable
- A many-to-many through a join table, with add and remove writing the join row
- Lookups and rollups resolved at query time, never stored

QUERY SAFETY, WHICH IS NOT NEGOTIABLE
- Every query parameterised. Filters compiled from an explicit structure, never assembled from text a caller supplied
- A statement timeout and a row cap on every list. One unbounded query on a large table takes the production database down, and this tool sits directly on it
- Read against a replica or a read-only connection where one exists, and make writes an explicit permission
- Default deny on every table until a role is granted it

OPERATIONS
- .env: TARGET_DATABASE_URL, DATABASE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, HASH_SALT
- Migrations for this tool's own tables on boot, each once
- Behind whatever the company already uses for staff access; this is a direct window into production data
- Nightly backup of the configuration database; the real data is backed up by whoever owns it
- Health endpoint touching both databases

WHAT MATTERS MOST
The query layer and the grid, in that order. Get parameterisation, timeouts, row caps and permissions right before a single cell is editable — this tool is a standing door into your production database, and the grid is where all the remaining time will go.

Give me the repository, migrations, .env.example, an introspection run against a seed schema, and a README with deploy steps behind Caddy and the network placement spelled out.