Built one feature at a time,
with the specs in the repo.
Suparbase is a single-author project. Every feature is a spec-kit markdown file committed alongside the code. Every release is a git tag. There is no roadmap deck. There is no quarterly OKR. There is just the next spec.
Why this exists
Suparbase started as a frustration. Every Supabase admin tool I'd tried either stored the API key in localStorage (foot-gun), required a separate password manager (friction), or shipped only the table browser (no RLS debugging, no audit, no AI). I wanted one workspace that did the obvious thing: authenticated, server-side, encrypted, with the affordances of a real product.
Twenty-plus specs later, here we are. The product ships an SQL playground, RLS debugger, AI write actions with diff cards, row history, storage browser, auth users with session inspector, custom actions, connection dashboards, team workspace, inline cell editing, global search, and seven archetype list views (Users, Content, Logs, Commerce, Tasks, Messages, plus a Generic fallback). Every one of these lives in specs/0XX-name/spec.md.
The product is opinionated where being opinionated saves the user time: archetype detection picks the right detail view automatically, the AI agent has narrow tools so it can't fabricate columns, and writes always go through an audit log. Where opinion gets in the way: the SQL playground is one toggle away from write-mode and the RLS simulator runs raw SQL, both with the appropriate safety rails.
Four rules that decide every PR
The key never reaches the browser.
Every PostgREST call is proxied through an authenticated route handler. Keys are AES-256-GCM encrypted at rest. The browser holds only a session cookie.
Specs before code.
Every feature has a markdown spec under specs/ that's committed alongside the implementation. The spec carries the design notes and the constraints; the code is the realisation.
One feature, one commit.
Releases bundle features but each feature is its own atomic commit. Anything can be reverted independently without disturbing the rest.
AI assists; humans commit.
The AI chat can draft writes, but every change to the user's data goes through an explicit Apply click in the UI. The server re-validates after the user confirms.
The full Constitution lives at .specify/memory/constitution.md in the repo. It's terser than most: nine principles, each one a single paragraph, each one cited by spec PRs that touch the relevant surface.
What it's built with
No exotic dependencies. Everything below is mainstream, well-supported, and easy to operate.
- Next.js 15
- App-router framework + route handlers
- Drizzle ORM
- Schema, migrations, queries
- Postgres
- Sessions, connections, audit log, analysis cache
- NextAuth v5
- Email + password and GitHub OAuth
- Tailwind CSS
- Styling, with a hairline-driven design system
- Radix Primitives
- Dialog, Popover, Dropdown, Tooltip, Tabs
- TanStack Query
- Client cache for schema + rows
- postgres-js
- Direct Postgres for RLS debugger + SQL playground
- OpenRouter
- AI chat + schema analysis (BYO key)
The spec-kit workflow
Each feature starts as a markdown spec that answers: goal, scope, server design, API surface, UX, security, what's out of scope. Implementation follows. The commit message references the spec. Thirty features have shipped this way.
See the changelogFree tier, forever
One Supabase connection, the full admin surface, no credit card. Paid plans cover teams and unlimited projects. Feedback always welcome.
Get in touchCurious enough to try?
Five minutes to your first connection. No credit card.