What Supabase is, and who it is for
Supabase is an open-source backend platform built on PostgreSQL. It bundles a database, authentication, file storage, edge functions, and realtime into one product, and it is genuinely great at all of them. Its philosophy is to give you the real thing — an actual Postgres database you can query, index, and extend without limits.
That philosophy is also the catch. Supabase is built for developers, and it expects developer habits: you design a schema, you run migrations when it changes, and you secure your data by writing rules. For someone shipping a polished app through Cursor or Lovable who has never written SQL, those expectations are exactly the wall they were trying to avoid.
The Row Level Security trap
This is the single most important thing for a non-technical builder to understand. Supabase gives every project an anon key that is meant to be public — it ships in your frontend bundle. On its own, that key can touch your whole database.
What makes it safe is Row Level Security — policies, written in SQL, that you must add to every table to say who can read or change which rows. Supabase's own docs are emphatic about it. The failure mode is quiet: a builder who has tables but skips RLS has, in effect, published their database. The data leaks people report from no-code apps are very often exactly this.
Cradler removes the trap rather than asking you to remember it. Tables are deny-by-default. For each table you decide, with a dashboard toggle, whether the public anon key may read, insert, update, or delete. The service key, for server code only, bypasses those checks. There is no policy language, and there is no “forgot to turn it on” state — closed is the default.
Schema and migrations
On Supabase, your schema is something you own and evolve. Add a field to a form and you add a column — through the table editor, a SQL statement, or a migration file checked into your repo. AI tools help, but they help by generating SQL you are expected to read and apply. The schema is a thing you maintain.
Cradler treats the schema as a consequence of your data, not a prerequisite for it. The first time your app saves a record, Cradler creates the table and infers the column types from the values. The first time it saves a record with a new field, Cradler runs an ADD COLUMN — a millisecond metadata change. You never write a migration because there is never a moment where the schema and the code are out of sync waiting for one.
Cradler vs. Supabase, point by point
Schema and migrations
Supabase
You design tables and write migrations — in SQL, the table editor, or via an AI that still generates SQL you review.
Cradler
The schema auto-evolves. The first insert creates the table; a new field adds a column. There is no migration to write.
Securing a public key
Supabase
The anon key is safe only if you write Row Level Security policies in SQL for every table. Forget one and it is readable by anyone.
Cradler
Tables are deny-by-default. You toggle read/insert/update/delete per table in the dashboard — no policy language.
Database and file storage
Supabase
Both are included, but configured as separate products with their own concepts (buckets, storage policies).
Cradler
One project covers data and files. Upload through the same SDK; one set of keys, one bill.
Free tier behavior
Supabase
Generous, but free projects pause after a week with no requests — your app goes offline until you resume it.
Cradler
A permanent free tier with no card, and your project does not pause for inactivity.
AI tooling
Supabase
A typed client and an MCP server exist; they are aimed at developers who can verify the generated SQL.
Cradler
Typed SDK, per-project generated types, an llms.txt, and an MCP server — built so non-coders never see SQL at all.
The same feature, both ways
Storing a contact-form submission on Supabase means: create the messages table, then write an RLS policy so the anon key may insert into it — something like create policy "anon insert" on messages for insert to anon with check (true) — and only then call the client. On Cradler, you turn insert on for the table in the dashboard and write:
import { createClient } from "@cradler/sdk";
const cradler = createClient({
url: process.env.NEXT_PUBLIC_CRADLER_URL!,
projectId: process.env.NEXT_PUBLIC_CRADLER_PROJECT_ID!,
apiKey: process.env.NEXT_PUBLIC_CRADLER_ANON_KEY!,
});
// No CREATE TABLE, no migration, no RLS policy.
// The table appears on this first insert.
export async function sendMessage(name: string, body: string) {
await cradler.from("messages").insert({ name, body });
}Same database engine underneath. The difference is everything you did not have to do.
When to choose Supabase instead
Cradler is not trying to be Supabase, and there are real reasons to pick Supabase:
- You are a developer, or working with one, and you want direct SQL — joins, views, custom indexes, Postgres extensions.
- You need built-in user authentication, realtime subscriptions, or edge functions today. Cradler's MVP focuses on database and storage; those are not in it yet.
- You want a local-first development workflow with the Supabase CLI and migrations checked into version control.
- You need fine-grained, per-row authorization rules that go beyond table-level permissions.
If those describe you, Supabase is the better tool and you should use it. Cradler is for the builder on the other side of that line — the one who picked an AI coding tool precisely so they would never have to write a policy.