| Primary job |
Assemble and inspect one backend contract for an app: relational models, auth, REST endpoints, workflows, validation, docs, and publish state. |
Provide a Postgres development platform with database, Auth, Storage, Realtime, Edge Functions, APIs, SDKs, and operational services. |
| Starting point |
Start from product requirements or an existing frontend, then review the generated resources and behavior before publishing. |
Start from a Postgres project, schema, starter, migration, or SQL and wire the application against Supabase services. |
| Data and authorization |
Relational models, relationships, managed product JWT auth, roles, permissions, and endpoint-level workflow checks. Project authorization still requires review. |
A full Postgres database with Auth-integrated Row Level Security. Teams must correctly enable and design RLS policies for exposed schemas. |
| API model |
Published REST routes can include request validation, auth context, conditions, filters, external calls, and multi-step business behavior. |
PostgREST automatically reflects the database schema into a CRUD-oriented REST API; custom database functions and Edge Functions handle additional behavior. |
| Business logic |
Visual workflows, functions, tasks, triggers, and supported visual-to-code roundtrips keep custom backend behavior in the project graph. |
Business logic typically lives in SQL functions, RLS policies, database triggers, TypeScript Edge Functions, or application code. |
| Realtime and files |
Project channels and file-related integrations exist, but exact authorization, reconnect, storage, and scale requirements need project testing. |
Realtime supports database changes, Broadcast and Presence; Storage integrates file access with Postgres and RLS. |
| Coding-agent workflow |
Direct project MCP supports inspection, preview, mutation, validation, publish, review, and handoff tools. Public-to-project handoff remains fail-closed. |
The official Supabase MCP supports project-scoped and read-only modes, SQL and migration tools, logs, advisors, Edge Functions, types, and docs search. Supabase advises against connecting it to production data. |
| Frontend handoff |
Produces OpenAPI, JSON and Markdown docs, JavaScript and TypeScript SDK artifacts, declarations, snippets, auth notes, and publish-state context. |
Provides mature client SDKs plus self-documenting generated Data APIs; the team owns the broader application architecture and handoff process. |
| Hosting and portability |
Hosted project runtimes and export surfaces exist, but Spala is not open source and does not provide a generic customer self-host installer. |
The managed platform is operated by Supabase; an official Docker self-host path exists, with the operator responsible for security, scaling, backups, monitoring, and maintenance. |
| Migration and backup |
Project, data, and runtime export surfaces help with handoff but do not prove one-click portability or no lock-in. |
Postgres schema and data can be dumped and restored; moving Auth configuration, Storage objects, Edge Functions, and other platform services requires separate work. |
| Pricing and maturity |
Default developer setup is self-serve through the dashboard, with custom managed-build help only when requested. Spala has narrower public production and trust evidence. |
A free tier and usage-based Pro plan start self-serve; Team and Enterprise add governance and support. Supabase is the substantially more mature platform. |