Compare · Open-source Postgres platform
Aaly vs Supabase
Supabase gives you a hosted Postgres database and generates a REST and GraphQL API over the tables you create, plus auth, edge functions, and file storage. Its pitch is "build in a weekend, scale to millions". You get real Postgres and you own it.
Choose Supabase instead if
- ·You want direct SQL access, or need Postgres-specific features such as extensions, complex joins, stored procedures, analytical queries.
- ·You need realtime. Supabase ships live subscriptions; Aaly has none, and unlike most gaps this one isn't on the roadmap.
- ·You need access rules finer than the tenant boundary. RLS can express per-row, per-role and per-column conditions; Aaly's isolation is tenant-scoped, and role- and field-level permissions aren't built yet.
- ·Your team already writes and reviews migrations and RLS policies comfortably, in which case the cost Aaly removes is one you're already paying without much pain.
Where Aaly differs
- →You still own Supabase's migrations, RLS policies, and any edge functions you write. That ownership is the thing Aaly's whole bet says becomes a liability rather than a feature, once a product is past its first version and changing weekly.
- →Aaly derives the running API from a definition, so there's no migration to write and no policy that can be omitted on a new entity.
- →Tenant isolation is the axis this comparison actually turns on, and it's worth more than a table row. The section below walks through what each product makes you write.
| Supabase | Aaly | |
|---|---|---|
| Data layer | Real Postgres you manage directly | A definition Aaly serves the API from |
| Schema changes | You write and run migrations | Change the definition; no migration |
| Tenant isolation | RLS policies you author, per table | A project flag, enforced on every request |
| Access granularity | Per-row, per-role, per-column via RLS | Tenant-level; roles and field rules not built yet |
| Realtime | Live subscriptions built in | Not available, and not on the roadmap |
| Server-side logic | Edge functions (TypeScript / Deno) | Functions (Python) on the request lifecycle |
| File storage | Built in | Built in: presigned upload, files entity |
| Billing | Usage-based, per-project plans | Usage-based, no per-seat charge |
The difference that matters
Where tenant isolation lives
Both products can build a multi-tenant SaaS. The difference is where the rule that keeps tenant A out of tenant B's data actually lives, and therefore what has to go right every single time the schema changes.
In Supabase, isolation is row-level security: SQL policies you author per table and Postgres enforces. In Aaly, it's a property of the project, applied by the platform on every request before your code is reached.
Supabase: per table, every table
-- repeated for EVERY table you create alter table orders enable row level security; create policy tenant_isolation on orders for all using (tenant_id = auth.jwt() ->> 'tenant_id');
Two steps, repeated for every new table. A table created without the first one is readable by anyone holding the anon key.
Aaly: once, for the project
{ "project": "helpdesk", "multiTenant": true }Every entity in the project is scoped from the moment it exists. There is no per-entity step to forget.
This is not an argument that RLS is bad. It's a mature, powerful mechanism, and a team fluent in it can express access rules far more specific than anything Aaly offers today, which is exactly why the list above says to choose Supabase if you need them. Supabase also flags tables without RLS in its dashboard and its linter.
It's an argument about what happens when the author is an AI agent changing the schema repeatedly, at speed. Adding a table is one call. Remembering that the table also needs RLS switched on, and a correct policy written against the right claim, is a second thing the agent has to not skip. When it does skip it, nothing fails loudly. The table simply answers to whoever asks. That is the shape of the publicly reported data exposures in AI-built apps.
Aaly's bet is that a guarantee this important shouldn't be something anyone, human or agent, can forget to write.