Development

Schema

Jalaran Schema checks a Postgres or Supabase schema against real conventions — UUID keys, owner scoping, row-level security, foreign-key indexes, timestamps — and never runs a migration.

Open Schema →Create free account

Who Schema is for

For anyone building on Supabase, where the expensive mistakes are structural and silent: a table with no row-level security policy works perfectly in development and exposes every row in production.

What Schema does

Paste a schema and Schema runs deterministic checks against the conventions that actually cause problems when missed — UUID primary keys, a user-scoping column, row-level security with an owner policy, an index on every foreign key, timestamps, and consistent naming. These are not style preferences: a missing foreign-key index is a performance cliff you meet at scale, and a missing RLS policy is a data breach. It is paste-and-review only, so it cannot damage a database while telling you what is wrong with it.

UUID primary key, user scoping and RLS policy checks
Missing foreign-key index detection
Naming convention validation
Review only — never runs a migration

How Schema works

Paste the schema
Your DDL. Nothing is connected to and nothing is executed.
Read the deterministic checks
UUID keys, owner scoping, RLS with an owner policy, FK indexes, timestamps, naming.
Fix what matters first
A missing RLS policy is a breach; a naming inconsistency is untidiness. The findings distinguish them.
Apply migrations yourself
Schema never executes anything. You run the migration deliberately, in your own tooling.

What Schema does not do

Schema reviews what you paste. It does not connect to your database, inspect a live schema, or see your actual data volumes and query patterns, so it flags a missing index without knowing whether that table has twelve rows. It never executes a migration, deliberately. Conventions are opinionated toward Supabase multi-tenant patterns and will disagree with a schema built on different, equally valid assumptions.

Common questions

Can it break my database?

No. It is paste-and-review only — it never connects to a database and never executes a migration. It can tell you what is wrong; applying the fix is deliberately yours.

Why does it care so much about RLS?

Because a Supabase table without a row-level security policy behaves perfectly in development and exposes every row in production. It is the highest-consequence, easiest-to-miss defect in the whole category.

Are its conventions the only right ones?

No. They are opinionated toward Supabase multi-tenant patterns. A schema built on different assumptions will disagree, and that disagreement may well be correct.