Guide

Claude Code database options, compared honestly

Every Claude Code project reaches the same fork: the prototype works, and now it needs to keep data. The choices differ less in what they can store and more in how much of the surrounding work, auth, admin, hosting, migrations, the agent can do for you, and how much lands back on your plate. This is a comparison from the point of view of someone shipping with an agent, not a benchmark.

Published September 2, 20264 min read

The four realistic options

OptionWhat Claude Code can do through MCPWhat you still doBest for
SQLite in the repoWrite the schema and queries as codeEverything: hosting, auth, backups, adminLocal tools, CLIs, prototypes that never leave your machine
Postgres + a Postgres MCP serverInspect schema, run SQL, optionally write rowsProvision the database, auth, migrations, an admin, backupsDevelopers who want SQL and own the stack
SupabaseManage tables, run SQL, read logs through the Supabase MCPDesign auth rules, RLS policies, an admin for non-developersApps with real users where you will write a frontend anyway
TaskLiteCreate projects, typed boards, REST endpoints, keys; build the admin implicitlyWrite the frontend if you need a custom oneApps a business will operate day to day: orders, bookings, CRM, inventory

Setup time, measured

The numbers below are for a small app with two related tables (customers, orders), a status field and one endpoint per table, starting from an empty Claude Code session, measured on 2 September 2026. They include the agent's tool calls and your own clicks, not the frontend.

OptionTime to first row storedTime to an admin someone else can use
SQLite~5 minutesNot included; a day if you build one
Postgres MCP~30 minutes including provisioningNot included; half a day with a generator
Supabase~20 minutes including project creation and RLSTable editor exists; a client-facing admin is a day
TaskLite~2 minutesIncluded: boards, views, forms, automations

What the agent gets wrong with each

  • SQLite / Postgres: the agent happily stores dates and phone numbers as text. Nothing stops it, and you find out when sorting breaks.
  • Supabase: RLS policies are easy to get subtly wrong, and the agent cannot test them from the outside without a user context.
  • TaskLite: the agent must read real column ids with get_board_schema before writing rows; skipping that step produces a silent failure inside a 200 response. The server also refuses obvious type mismatches, which the agent sometimes reports as an error rather than retrying with the suggested type.

Auth and who acts as whom

With Postgres or SQLite the agent holds whatever credential you gave it, usually full access. Supabase separates the service key from user sessions, which is right, but pushes the policy work to you. TaskLite issues Claude short-lived tokens scoped to your permissions, never admin rights; app endpoints use their own keys, held server-side, with optional per-user row security through an X-App-User header.

The admin question

This is the deciding factor more often than the database engine. If the person who will use the app every day is you, a table editor is enough. If it is a bakery owner, a clinic, a small team, they need statuses, a calendar, a form their customers can fill, and a way to change a field without calling you. That is what TaskLite is: the admin is the product, and the database sits underneath it. The one-prompt backend guide walks through it.

A fair recommendation

  • Personal tool or experiment: SQLite.
  • You want SQL, own the infrastructure, and will build the admin: Postgres MCP.
  • Consumer app with auth and a custom frontend, developer-operated: Supabase.
  • Business app someone else operates, forms and portals included: TaskLite.

Frequently asked questions

Can I use TaskLite and Supabase together?
Yes. Some teams keep user auth and files in Supabase and put the operational data, orders, tasks, approvals, in TaskLite where the business edits it. The TaskLite REST API is called from the Supabase edge function or the Next.js server.
Does TaskLite support relations and computed fields?
Yes: relation, lookup, rollup and formula columns. Foreign keys become relation columns; aggregates become rollups.
Can I export to Postgres later?
Every board exports to CSV or through the API. A move to Postgres is a script, not a migration project.