gridbase — an open-source Airtable that fronts your own database

gridbase is a metadata-driven, database-backed workspace. It gives you Airtable's spreadsheet-meets-database experience — tables, multiple views, relations, formulas, lookups, filters, and inline editing — over your own data source instead of a captive store.

The whole UI and API render from a registry (meta_tables / meta_fields / meta_views), so there is zero per-entity code: define your tables as metadata and everything renders and edits generically. The storage sits behind a thin connector boundary (D1/SQLite today; Postgres, Mongo, and read-only warehouses on the roadmap) — that connector layer is the differentiator versus other open-source Airtable clones, which own their database.

Features

• Views: Table (inline-editable grid), Kanban, Calendar (month grid, drag-to-reschedule), Gallery (card grid with optional cover images), Gantt (timeline bars from start/end date fields), Detail panel, and Form (focused entry). Every view type has an in-toolbar config panel (stack field, date field, cover field, start/end fields, …).
• Grid power features: drag-to-resize and drag-to-reorder columns; grouped rows with collapsible section headers; a per-column header menu (sort, group-by, hide, color rows); a sticky summary footer (count / sum / avg / min / max per column); row coloring by a select field; row selection with bulk delete; cursor-key navigation with Enter-to-edit and ⌘C/⌘V clipboard; a record side-peek drawer with inline editing; "Load more" pagination.
• Kanban power features: drag cards between columns (writes the stack field) and reorder cards within a column (persisted); per-column quick-add; collapsible columns; custom column order; card preview fields follow the shared field editor.
• Dashboards & reports: a workspace-level report composer (/d) — KPI, bar, line, and table widgets over any table, powered by a grouped-aggregation endpoint with date bucketing; widgets are validated at write time.
• Relations: linked records with searchable link pickers; click through to navigate; collapsible long link lists.
• Computed fields: declarative sum / ratio / bucket formulas; lookups that pull a field across a link; rollups (count / sum / avg / min / max across a link) — all computed on read.
• Self-service schema: add and delete fields from the UI (including a rollup builder); stored fields get an additive ALTER TABLE, computed fields are metadata-only.
• Filters, sorts, freeze: per-view saved filters (with one-level AND/OR groups), sorts (including by linked sub-fields), field show/hide/reorder; freeze header row and leading columns.
• Editing: inline cell editing per type, add/delete records, a new-record modal, and CSV import (column → field mapping, chunked create).
• Field types: text, longtext, number, date, datetime, single/multi select, checkbox, url, email, json, formula, link, lookup, rollup.
• Mobile-aware: dynamic-viewport layout, safe-area padding, wrapping toolbars, viewport-clamped popovers, and a sidebar that collapses to an icon rail and expands as an overlay on phones.
• Seams for production: every entity table carries a nullable workspace_id (multi-tenant seam) and meta_tables.source_kind / source_ref (connector seam).

Architecture (at a glance)

apps/web  (Next.js)
  ├─ Server Components ── read ──┐  (GRID_API_SECRET stays server-side)
  └─ app/api/grid/[...path] BFF ─┤  (client mutations; attaches the Bearer)
                                 ▼
        packages/api (Cloudflare Worker, binds D1) ──▶ D1 / SQLite

• packages/api — a Bearer-gated HTTP API over D1. Reads the registry, computes formulas, resolves links/lookups, applies filters/sorts, and handles writes.
• apps/web — the Next.js UI. Renders entirely from /v1/meta; a thin BFF proxies client mutations so the API secret never reaches the browser.
• packages/sdk — a typed client for the API, usable from Node (HTTPS + Bearer) or inside a Worker (service binding).

See docs/ARCHITECTURE.md for the full picture.

Quick start (Cloudflare Workers + D1)

pnpm install

# 1. Create a D1 database and wire up the api Worker.
cp wrangler.toml.example packages/api/wrangler.toml
cd packages/api && npx wrangler d1 create gridbase   # paste the id into wrangler.toml

# 2. Generate the demo migrations + seed.
cd ../.. && node scripts/gen-sql.mjs
node scripts/seed.mjs > /tmp/seed.sql

# 3. Apply migrations + seed (use --local for the wrangler dev sqlite).
cd packages/api
npx wrangler d1 migrations apply gridbase --local
npx wrangler d1 execute gridbase --local --file=/tmp/seed.sql

# 4. Run the api locally (open, no secret) and the web app.
echo 'GRID_DEV_OPEN=1' > .dev.vars
npx wrangler dev --port 8799
# in another shell:
cd ../../apps/web && GRID_API_URL=http://localhost:8799 pnpm dev

Open the web app and you'll see the demo CRM (Companies / Contacts / Deals) with Table, Kanban, Calendar, Gallery, and Gantt views plus the dashboards composer at /d.

To deploy, see docs/DEPLOYMENT.md.

Repo layout

apps/web            Next.js UI (@gridbase/web)
packages/api        HTTP data API — Cloudflare Worker over D1 (@gridbase/api)
packages/sdk        typed client for the API (@gridbase/sdk)
examples/           demo-schema.mjs — a neutral CRM example
scripts/            gen-sql.mjs (emit migrations), seed.mjs (registry + demo data)
docs/               ARCHITECTURE, DEPLOYMENT, ROADMAP

Docs

• Architecture
• Deployment
• Roadmap
• Contributing

License

MIT.