Supabase positions itself as the open-source Firebase alternative, but that comparison undersells what it actually is. While Firebase gives you a proprietary NoSQL database with proprietary APIs, Supabase gives you a full PostgreSQL database with a complete backend-as-a-service layer on top. The difference is fundamental: your data lives in a real relational database that you can query with standard SQL, migrate to any PostgreSQL host, and extend with standard PostgreSQL features. You are never locked in.
The database is the core of Supabase, and it is genuinely PostgreSQL — not a PostgreSQL-compatible layer, not a simplified wrapper, but actual PostgreSQL 15 with all extensions, functions, triggers, and capabilities. You get full SQL access, can install extensions like PostGIS for geospatial data or pg_vector for AI embeddings, and can write complex queries with CTEs, window functions, and recursive queries. The SQL editor in the Supabase dashboard lets you run queries directly, which is incredibly useful for debugging and data exploration.
The Table Editor provides a spreadsheet-like interface for browsing and editing data. For developers, it is a convenient way to inspect data without writing queries. For non-technical team members, it provides data access without needing to learn SQL. You can filter, sort, and edit rows directly in the browser. It is not a replacement for a proper database client, but for quick lookups and data corrections, it is remarkably useful.
Authentication in Supabase covers the common patterns that every application needs. Email and password authentication works out of the box. Social login supports Google, GitHub, Discord, Apple, Twitter, and many more providers. Magic links provide passwordless authentication via email. Phone authentication with SMS verification is supported. For enterprise applications, SAML SSO is available. The auth system generates and validates JWTs, integrates with Row Level Security, and provides session management.
Row Level Security (RLS) is the authorization model that makes Supabase uniquely powerful. RLS policies are PostgreSQL policies that control which rows a user can read, insert, update, or delete based on their authentication status and claims. Instead of implementing authorization logic in your application code, you define it at the database level. This means your data is protected regardless of which client or API accesses it. RLS policies can be as simple as "users can only read their own rows" or as complex as "managers can read rows from their team members in the same department."
The complexity of RLS is both its strength and its primary learning curve. Writing effective RLS policies requires understanding PostgreSQL policy syntax, how JWTs are extracted in policy functions, and how policies interact with each other. Debugging why a query returns empty results (because an RLS policy is blocking access) can be frustrating for developers new to the concept. Supabase provides documentation and examples, but RLS mastery takes time and practice.