Should you build your own Quickbase?

Build a closest honest personal substitute for Quickbase in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and Docker Compose; do not offer alternative stacks.
The core loop is: model structured records in a constrained operational database for one small team, provide form, grid, kanban, and filtered views, and expose a documented API.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Create workspaces, bases, tables, fields, records, attachments, relations, and saved views.
Support text, number, currency, date, boolean, select, formula-lite, and relation field types.
Build grid, form, kanban, and record-detail views from one canonical schema.
Add role-based permissions, optimistic concurrency checks, audit history, and trash restore.
Provide CSV import or export and a token-authenticated REST API generated from the schema.
Ship migrations, seed data, backups, health checks, and a schema export format.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out full spreadsheet formula compatibility.
Deliberately leave out hundreds of automations and integrations.
Deliberately leave out large-enterprise governance and vendor-managed scale.
Finish by running the tests and listing the exact commands used.