What is Supabase?

Supabase is an open-source backend-as-a-service built on PostgreSQL. It provides authentication, file storage, auto-generated REST APIs, real-time subscriptions, and serverless edge functions in a single managed platform, with no vendor lock-in and the option to self-host the entire stack.

What makes Supabase different

Open source by design. Every component, from the database to the authentication layer, can be inspected, modified, and self-hosted. You are never locked into a vendor, and you retain full control over your infrastructure.

PostgreSQL at the core. Rather than a proprietary NoSQL store, Supabase builds on PostgreSQL: ACID compliance, foreign keys, triggers, stored procedures, joins, and a rich extension ecosystem. It is a battle-tested system that powers large-scale production applications worldwide.

Developer-first ergonomics. Auto-generated APIs, type-safe client libraries, and a browser-based SQL editor let teams move quickly. Direct SQL access means you are never constrained by framework limitations. This positions Supabase as a practical alternative to Firebase; for a direct comparison of the two, see the difference between Firebase and Supabase.

Core services

PostgreSQL database

Supabase exposes a full PostgreSQL instance. Developers query data with standard SQL, perform joins and transactions, and enable extensions such as pgvector for vector similarity search, PostGIS for geospatial queries, or full-text search, all within the same project.

Instant REST APIs

When you create a table, Supabase automatically generates RESTful endpoints for it. No back-end code is required to start reading and writing data. Access control is enforced through PostgreSQL row-level security policies, applied consistently at the database level across every endpoint.

Authentication

Supabase Auth supports OAuth 2.0, email and password, magic links, and third-party providers including Google, GitHub, and Azure. All user data, sessions, refresh tokens, and metadata are stored in your own database as readable rows and tables. There is no hidden identity layer; authentication events can be audited directly in SQL.

Storage

Object storage for images, videos, and documents is secured using the same row-level security rules as the rest of your database, keeping file permissions in sync with user data. Buckets can be public or private, presigned URLs grant temporary access to protected files, and on-the-fly image transformations remove the need for a separate media service.

Edge Functions

Serverless logic runs on Deno close to users, with TypeScript support and direct access to your database and other Supabase services. Edge Functions suit webhooks, payment processing, and custom data pipelines without requiring separate infrastructure.

Real-time subscriptions

Supabase broadcasts database changes to connected clients using PostgreSQL's native replication system. Subscriptions can target specific tables or rows, enabling reactive interfaces for collaborative tools, dashboards, and messaging features. Presence tracking is also supported.

Pricing model

Supabase charges on a usage basis across two dimensions: base resources (database storage, file storage, bandwidth, API requests) and compute (the processing capacity of the PostgreSQL instance). These scale independently, so you do not pay for excess compute when you only need more storage.

All usage metrics are visible in real time on the dashboard: database size, API calls, bandwidth, and function invocations. Spending caps prevent unexpected bills. Core functionality, including auto-generated APIs, authentication, and real-time subscriptions, is available on the free tier. Daily backups, point-in-time recovery, and priority support are gated behind paid plans. Enterprise plans offer dedicated infrastructure, custom SLAs, and compliance support. The open-source codebase means self-hosting is always an option if you want complete cost control.

Supabase vs Firebase

The most common comparison is with Firebase. Firebase uses proprietary NoSQL stores (Firestore and the Realtime Database) and is tightly coupled to the Google Cloud ecosystem. Supabase uses standard SQL, is fully open source, and can run anywhere. Teams comfortable with relational data modelling, complex queries, or the need to avoid vendor lock-in tend to favour Supabase; teams that want the deepest integration with Google services or a purely document-oriented data model may still prefer Firebase.

In an AI-native team

Coding agents can scaffold Supabase projects quickly, generating table schemas, row-level security policies, and client-side data hooks from a short prompt. Engineers still need to verify that generated policies are correctly scoped and that foreign key relationships hold under real query patterns, since agents will occasionally produce plausible-looking SQL that silently bypasses access controls. Familiarity with agentic coding and context engineering helps teams get consistent output when working with the Supabase CLI, migrations, and Edge Functions across multiple sessions.

What we test for

When assessing engineers who work with Supabase, we follow how we vet: a fundamentals assessment without AI tools covers SQL correctness, row-level security logic, and schema design; an AI-native session examines how the engineer directs a coding agent, reviews the generated code, and catches errors in policies or migrations they did not write themselves. Strong candidates can reason about what the database is actually doing regardless of how the code was produced.

Short answers