Interactive architecture map of the open-source Firebase alternative — PostgreSQL at the core with realtime subscriptions, GoTrue authentication, pgvector embeddings, object storage, Edge Functions, and PostgREST API generation.
Supabase is an open-source backend-as-a-service built entirely around PostgreSQL. Rather than building proprietary databases, Supabase wraps battle-tested open-source tools — PostgREST, GoTrue, Realtime, Storage, and Deno-based Edge Functions — into a unified developer platform with auto-generated APIs, dashboard, and client libraries.
graph TD
subgraph Clients["Client Layer"]
JS["supabase-js
(TypeScript)"]
DART["supabase-dart
(Flutter)"]
SWIFT["supabase-swift
(iOS)"]
KT["supabase-kt
(Kotlin)"]
DASH["Studio
Dashboard"]
CLI["Supabase CLI"]
end
subgraph Gateway["API Gateway (Kong / Envoy)"]
GW["Kong Gateway
+ JWT Validation"]
end
subgraph Services["Core Services"]
REST["PostgREST
(auto-generated REST)"]
AUTH["GoTrue
(Auth)"]
RT["Realtime
(Elixir)"]
STOR["Storage API
(S3-compatible)"]
EDGE["Edge Functions
(Deno Deploy)"]
META["postgres-meta
(Mgmt API)"]
end
subgraph Database["PostgreSQL Core"]
PG["PostgreSQL 15+"]
PGVEC["pgvector
(Embeddings)"]
RLS["Row Level Security"]
PUB["Logical Replication
& Publications"]
end
Clients --> GW
GW --> REST
GW --> AUTH
GW --> RT
GW --> STOR
GW --> EDGE
GW --> META
REST --> PG
AUTH --> PG
RT --> PUB
STOR --> PG
EDGE --> REST
META --> PG
style GW fill:#162a21,stroke:#48bb78,color:#fff
style REST fill:#0d1a14,stroke:#3ecf8e,color:#fff
style AUTH fill:#0d1a14,stroke:#f56565,color:#fff
style RT fill:#0d1a14,stroke:#f5a623,color:#fff
style STOR fill:#0d1a14,stroke:#9f7aea,color:#fff
style EDGE fill:#0d1a14,stroke:#3fc5f0,color:#fff
style META fill:#0d1a14,stroke:#8faa9b,color:#fff
style PG fill:#111f19,stroke:#336791,color:#fff
style PGVEC fill:#111f19,stroke:#e879a0,color:#fff
style RLS fill:#111f19,stroke:#336791,color:#fff
style PUB fill:#111f19,stroke:#f5a623,color:#fff
Every Supabase feature maps to a standalone open-source tool. If Supabase disappeared tomorrow, your PostgreSQL database and all its data would still be accessible via standard tooling. There is zero vendor lock-in at the data layer.
PostgreSQL is not just the database — it is the platform. Supabase uses PostgreSQL as the single source of truth for everything: authentication tables, storage metadata, realtime configuration, and application data. Every service connects directly to PostgreSQL.
Supabase pre-installs 50+ PostgreSQL extensions on every project, giving developers access to advanced capabilities without custom configuration.
graph TD
subgraph Core["PostgreSQL Engine"]
PG["PostgreSQL 15+
(MVCC, WAL, Planner)"]
end
subgraph Security["Security & Auth"]
RLS["Row Level Security
(pg policies)"]
PGJWT["pgjwt
(JWT in SQL)"]
VAULT["Supabase Vault
(Encrypted Secrets)"]
end
subgraph Data["Data & Search"]
PGVEC["pgvector
(Embeddings)"]
FTS["Full Text Search
(tsvector/tsquery)"]
JSONB["JSONB
(Document Store)"]
PGTRGM["pg_trgm
(Fuzzy Matching)"]
end
subgraph Infra["Infrastructure"]
CRON["pg_cron
(Scheduled Jobs)"]
STAT["pg_stat_statements
(Query Analytics)"]
HOOKS["pg_net
(HTTP from SQL)"]
NOTIFY["LISTEN/NOTIFY
(Pub/Sub)"]
end
PG --> Security
PG --> Data
PG --> Infra
style PG fill:#0d1a14,stroke:#336791,color:#fff
style RLS fill:#111f19,stroke:#336791,color:#fff
style PGJWT fill:#111f19,stroke:#f56565,color:#fff
style VAULT fill:#111f19,stroke:#f56565,color:#fff
style PGVEC fill:#111f19,stroke:#e879a0,color:#fff
style FTS fill:#111f19,stroke:#3ecf8e,color:#fff
style JSONB fill:#111f19,stroke:#3ecf8e,color:#fff
style PGTRGM fill:#111f19,stroke:#3ecf8e,color:#fff
style CRON fill:#111f19,stroke:#f5a623,color:#fff
style STAT fill:#111f19,stroke:#3fc5f0,color:#fff
style HOOKS fill:#111f19,stroke:#3fc5f0,color:#fff
style NOTIFY fill:#111f19,stroke:#f5a623,color:#fff
RLS policies are PostgreSQL-native access control. Every table can have policies that filter rows based on the authenticated user's JWT claims, evaluated at the database level.
Transparent Column Encryption (TCE) powered by pgsodium. Secrets are encrypted at rest using a root key stored outside the database in a separate key management system.
Cron-style job scheduler running inside PostgreSQL. Enables periodic tasks like data cleanup, materialized view refresh, and analytics aggregation without external schedulers.
PostgREST is a standalone Haskell web server that generates a RESTful API directly from the PostgreSQL schema. Every table, view, and function becomes an API endpoint automatically. Supabase extends this with auto-generated TypeScript types and client library integration.
graph LR
CLIENT["Client
Request"] --> GW["Kong
Gateway"]
GW --> PARSE["PostgREST
Parse & Validate"]
PARSE --> PLAN["Query
Planning"]
PLAN --> RLS["RLS Policy
Evaluation"]
RLS --> EXEC["PostgreSQL
Execution"]
EXEC --> SER["JSON
Serialization"]
SER --> RESP["HTTP
Response"]
subgraph PostgREST["PostgREST Process (Haskell)"]
PARSE
PLAN
SER
end
subgraph PostgreSQL["PostgreSQL"]
RLS
EXEC
end
style CLIENT fill:#162a21,stroke:#48bb78,color:#fff
style GW fill:#162a21,stroke:#48bb78,color:#fff
style PARSE fill:#0d1a14,stroke:#3ecf8e,color:#fff
style PLAN fill:#0d1a14,stroke:#3ecf8e,color:#fff
style RLS fill:#111f19,stroke:#336791,color:#fff
style EXEC fill:#111f19,stroke:#336791,color:#fff
style SER fill:#0d1a14,stroke:#3ecf8e,color:#fff
style RESP fill:#162a21,stroke:#48bb78,color:#fff
PostgREST uses URL query parameters for filtering, ordering, and pagination. Operators like eq, gt, in, and cs (contains) map directly to PostgreSQL operators. Nested resource embedding uses foreign key relationships to auto-join tables.
PostgREST introspects the database schema on startup and caches it. A NOTIFY signal triggers cache reload when migrations run, ensuring the API stays in sync with schema changes.
Foreign key relationships become embeddable resources. A single request can fetch a user with all their posts and comments via ?select=*,posts(*,comments(*)) syntax.
PostgreSQL functions are exposed as POST endpoints at /rpc/function_name. This enables complex business logic to live in the database while remaining accessible via REST.
Supabase Auth is powered by GoTrue, a Go-based authentication server that manages user sign-up, sign-in, JWT token issuance, and identity provider integrations. User data lives in the auth schema within the same PostgreSQL database as application data.
sequenceDiagram
participant C as Client App
participant GW as Kong Gateway
participant GT as GoTrue (Auth)
participant PG as PostgreSQL
participant IDP as OAuth Provider
C->>GW: POST /auth/v1/signup
GW->>GT: Forward request
GT->>PG: INSERT auth.users
PG-->>GT: User created
GT-->>C: JWT access + refresh tokens
Note over C,IDP: OAuth Flow (Google, GitHub, etc.)
C->>GW: GET /auth/v1/authorize?provider=github
GW->>GT: Initiate OAuth
GT->>IDP: Redirect to provider
IDP-->>GT: Auth callback + code
GT->>IDP: Exchange code for token
IDP-->>GT: Provider token + profile
GT->>PG: UPSERT auth.users + auth.identities
GT-->>C: JWT tokens + redirect
GoTrue stores all authentication state in PostgreSQL's auth schema. The auth.users table is the source of truth, with related tables for identities, sessions, refresh tokens, MFA factors, and audit logs.
graph TD
subgraph AuthSchema["auth Schema (PostgreSQL)"]
USERS["auth.users
(core identity)"]
IDENT["auth.identities
(OAuth links)"]
SESS["auth.sessions
(active sessions)"]
REFRESH["auth.refresh_tokens"]
MFA["auth.mfa_factors
(TOTP/WebAuthn)"]
AUDIT["auth.audit_log_entries"]
end
subgraph Providers["Identity Providers"]
EMAIL["Email / Password"]
PHONE["Phone / OTP"]
MAGIC["Magic Link"]
OAUTH["OAuth 2.0
(30+ providers)"]
SAML["SAML 2.0
(Enterprise SSO)"]
end
subgraph Integration["Platform Integration"]
JWT["JWT Claims
(role, sub, metadata)"]
RLS["RLS Policies
auth.uid()"]
HOOK["Auth Hooks
(pg functions)"]
end
Providers --> USERS
USERS --> IDENT
USERS --> SESS
SESS --> REFRESH
USERS --> MFA
USERS --> AUDIT
USERS --> JWT
JWT --> RLS
USERS --> HOOK
style USERS fill:#0d1a14,stroke:#f56565,color:#fff
style IDENT fill:#111f19,stroke:#f56565,color:#fff
style SESS fill:#111f19,stroke:#f56565,color:#fff
style REFRESH fill:#111f19,stroke:#f56565,color:#fff
style MFA fill:#111f19,stroke:#f56565,color:#fff
style AUDIT fill:#111f19,stroke:#f56565,color:#fff
style JWT fill:#162a21,stroke:#3ecf8e,color:#fff
style RLS fill:#162a21,stroke:#336791,color:#fff
style HOOK fill:#162a21,stroke:#3ecf8e,color:#fff
When a client makes an API request with a JWT, PostgREST sets the PostgreSQL session role to authenticated and populates request.jwt.claims. RLS policies can then use auth.uid() and auth.jwt() to filter rows, making authorization happen entirely at the database level.
Supabase Realtime is an Elixir server that provides three multiplexed capabilities over a single WebSocket connection: database change streaming (CDC via PostgreSQL logical replication), Broadcast (low-latency pub/sub), and Presence (shared state tracking).
graph TD
subgraph PG["PostgreSQL"]
WAL["WAL (Write-Ahead Log)"]
PUB["Publication
(supabase_realtime)"]
SLOT["Replication Slot"]
end
subgraph Realtime["Realtime Server (Elixir/OTP)"]
CDC["CDC Listener
(logical replication)"]
BC["Broadcast
(ErlangDistribution)"]
PRES["Presence
(CRDTs)"]
CH["Channel Manager
(Phoenix Channels)"]
AUTH_CHECK["JWT Verification
& RLS Check"]
end
subgraph Clients["Connected Clients"]
WS1["WebSocket 1"]
WS2["WebSocket 2"]
WS3["WebSocket N"]
end
WAL --> PUB
PUB --> SLOT
SLOT --> CDC
CDC --> CH
BC --> CH
PRES --> CH
CH --> AUTH_CHECK
AUTH_CHECK --> WS1
AUTH_CHECK --> WS2
AUTH_CHECK --> WS3
style WAL fill:#111f19,stroke:#336791,color:#fff
style PUB fill:#111f19,stroke:#336791,color:#fff
style SLOT fill:#111f19,stroke:#336791,color:#fff
style CDC fill:#0d1a14,stroke:#f5a623,color:#fff
style BC fill:#0d1a14,stroke:#f5a623,color:#fff
style PRES fill:#0d1a14,stroke:#f5a623,color:#fff
style CH fill:#0d1a14,stroke:#f5a623,color:#fff
style AUTH_CHECK fill:#0d1a14,stroke:#f56565,color:#fff
Uses PostgreSQL logical replication to stream INSERT, UPDATE, and DELETE events. The supabase_realtime publication determines which tables are monitored. RLS policies filter events per subscriber.
Low-latency pub/sub for ephemeral messages between clients. Messages are distributed via Erlang distribution across the Realtime cluster without touching PostgreSQL.
Tracks shared state across clients using Phoenix Presence backed by CRDTs. Ideal for online indicators, cursor positions, and collaborative editing features.
Supabase Storage is an S3-compatible object storage system with PostgreSQL-backed metadata. File permissions use the same RLS policies as database tables, providing a unified authorization model across data and files.
graph LR
CLIENT["Client
Upload/Download"] --> GW["Kong
Gateway"]
GW --> API["Storage API
(Node.js)"]
API --> META["PostgreSQL
storage.objects
storage.buckets"]
API --> S3["S3-Compatible
Object Store"]
API --> TRANSFORM["Image
Transformations"]
TRANSFORM --> CDN["CDN
(Smart Cache)"]
META --> RLS["RLS Policies
(per-bucket)"]
subgraph Backend["Storage Backend Options"]
S3
LOCAL["Local Filesystem"]
CF["Cloudflare R2"]
end
style CLIENT fill:#162a21,stroke:#48bb78,color:#fff
style GW fill:#162a21,stroke:#48bb78,color:#fff
style API fill:#0d1a14,stroke:#9f7aea,color:#fff
style META fill:#111f19,stroke:#336791,color:#fff
style S3 fill:#0d1a14,stroke:#9f7aea,color:#fff
style TRANSFORM fill:#0d1a14,stroke:#9f7aea,color:#fff
style CDN fill:#0d1a14,stroke:#3fc5f0,color:#fff
style RLS fill:#111f19,stroke:#336791,color:#fff
style LOCAL fill:#0d1a14,stroke:#9f7aea,color:#fff
style CF fill:#0d1a14,stroke:#9f7aea,color:#fff
Each storage bucket maps to a PostgreSQL row in storage.buckets. RLS policies on storage.objects control who can upload, download, or delete files using the same auth.uid() patterns as database tables.
On-the-fly image resizing and format conversion via URL parameters. Supports width, height, quality, and format (WebP, AVIF) transformations cached at the CDN edge.
Large file uploads use the TUS protocol for resumable uploads. Clients can pause and resume uploads without restarting, critical for mobile and unreliable network conditions.
Edge Functions are server-side TypeScript functions powered by Deno. They run in isolated V8 environments close to users, providing a way to execute custom business logic, integrate third-party APIs, and handle webhooks without managing servers.
graph TD
REQ["HTTPS Request"] --> GW["Kong Gateway
+ JWT Extraction"]
GW --> RELAY["Edge Function
Relay"]
RELAY --> ISOLATE["Deno Isolate
(V8 Sandbox)"]
subgraph Runtime["Deno Runtime"]
ISOLATE --> TS["TypeScript
Function Code"]
TS --> SUPA["supabase-js
(Service Role)"]
TS --> FETCH["fetch()
(External APIs)"]
TS --> ENV["Env Variables
(Vault Secrets)"]
end
SUPA --> REST["PostgREST"]
SUPA --> AUTH_API["GoTrue"]
SUPA --> STOR_API["Storage API"]
REST --> PG["PostgreSQL"]
style REQ fill:#162a21,stroke:#48bb78,color:#fff
style GW fill:#162a21,stroke:#48bb78,color:#fff
style RELAY fill:#0d1a14,stroke:#3fc5f0,color:#fff
style ISOLATE fill:#0d1a14,stroke:#3fc5f0,color:#fff
style TS fill:#111f19,stroke:#3fc5f0,color:#fff
style SUPA fill:#111f19,stroke:#3ecf8e,color:#fff
style FETCH fill:#111f19,stroke:#3fc5f0,color:#fff
style ENV fill:#111f19,stroke:#f56565,color:#fff
style REST fill:#0d1a14,stroke:#3ecf8e,color:#fff
style AUTH_API fill:#0d1a14,stroke:#f56565,color:#fff
style STOR_API fill:#0d1a14,stroke:#9f7aea,color:#fff
style PG fill:#111f19,stroke:#336791,color:#fff
Supabase Edge Functions run on Deno Deploy's global infrastructure. Each function is an isolated V8 instance with no cold start penalty for warm functions. Functions have access to the Deno standard library, npm packages via specifiers, and can import from URLs.
Database webhook triggers fire Edge Functions in response to INSERT, UPDATE, or DELETE operations. The pg_net extension sends HTTP requests to the function URL from within PostgreSQL.
Combine pg_cron with pg_net to invoke Edge Functions on a schedule. Cron expressions run inside PostgreSQL, calling the function endpoint at the specified interval.
Supabase integrates pgvector directly into PostgreSQL, enabling vector similarity search alongside traditional relational queries. This makes it possible to build AI-powered applications — RAG pipelines, semantic search, recommendation engines — without a separate vector database.
graph LR
DOC["Documents
& Content"] --> CHUNK["Chunking
& Preprocessing"]
CHUNK --> EMBED["Embedding API
(OpenAI, Cohere)"]
EMBED --> STORE["PostgreSQL
vector column"]
QUERY["User Query"] --> QEMBED["Query
Embedding"]
QEMBED --> SEARCH["pgvector
Similarity Search"]
STORE --> SEARCH
SEARCH --> CONTEXT["Top-K
Results"]
CONTEXT --> LLM["LLM
(GPT, Claude)"]
LLM --> RESP["Generated
Response"]
subgraph Indexing["Index Types"]
IVF["IVFFlat
(Approximate)"]
HNSW["HNSW
(Graph-based)"]
end
STORE --> Indexing
style DOC fill:#162a21,stroke:#48bb78,color:#fff
style CHUNK fill:#0d1a14,stroke:#e879a0,color:#fff
style EMBED fill:#0d1a14,stroke:#e879a0,color:#fff
style STORE fill:#111f19,stroke:#336791,color:#fff
style QUERY fill:#162a21,stroke:#48bb78,color:#fff
style QEMBED fill:#0d1a14,stroke:#e879a0,color:#fff
style SEARCH fill:#111f19,stroke:#e879a0,color:#fff
style CONTEXT fill:#0d1a14,stroke:#e879a0,color:#fff
style LLM fill:#0d1a14,stroke:#3fc5f0,color:#fff
style RESP fill:#162a21,stroke:#48bb78,color:#fff
style IVF fill:#111f19,stroke:#336791,color:#fff
style HNSW fill:#111f19,stroke:#336791,color:#fff
Hierarchical Navigable Small World graph index provides fast approximate nearest neighbor search. Supports L2 distance, inner product, and cosine distance operators with tunable ef_construction and m parameters.
Combine vector similarity with traditional SQL filters in a single query. Use RLS policies to restrict vector search results by tenant, team, or user — security and AI in one query.
Official Python client for managing vector collections on Supabase. Provides a pandas-like API for creating collections, upserting vectors, and querying with metadata filters.
All client requests flow through an API gateway (Kong in hosted Supabase, configurable for self-hosted) that handles routing, rate limiting, JWT validation, and CORS. The gateway is the single entry point that dispatches to the correct backend service.
graph LR
CLIENT["Client Request
project-ref.supabase.co"] --> GW["API Gateway
(Kong)"]
GW -->|"/rest/v1/*"| REST["PostgREST"]
GW -->|"/auth/v1/*"| AUTH["GoTrue"]
GW -->|"/realtime/v1/*"| RT["Realtime
(WebSocket Upgrade)"]
GW -->|"/storage/v1/*"| STOR["Storage API"]
GW -->|"/functions/v1/*"| EDGE["Edge Functions"]
GW -->|"/pg/*"| META["postgres-meta
(Studio only)"]
GW -->|"/graphql/v1"| GRAPHQL["pg_graphql"]
style CLIENT fill:#162a21,stroke:#48bb78,color:#fff
style GW fill:#162a21,stroke:#48bb78,color:#fff
style REST fill:#0d1a14,stroke:#3ecf8e,color:#fff
style AUTH fill:#0d1a14,stroke:#f56565,color:#fff
style RT fill:#0d1a14,stroke:#f5a623,color:#fff
style STOR fill:#0d1a14,stroke:#9f7aea,color:#fff
style EDGE fill:#0d1a14,stroke:#3fc5f0,color:#fff
style META fill:#0d1a14,stroke:#8faa9b,color:#fff
style GRAPHQL fill:#0d1a14,stroke:#e879a0,color:#fff
| Route | Service | Auth | Protocol |
|---|---|---|---|
/rest/v1/* |
PostgREST | anon key or JWT | HTTP/REST |
/auth/v1/* |
GoTrue | anon key | HTTP/REST |
/realtime/v1/* |
Realtime | JWT in params | WebSocket |
/storage/v1/* |
Storage API | JWT | HTTP/REST + TUS |
/functions/v1/* |
Edge Functions | anon key or JWT | HTTP |
/graphql/v1 |
pg_graphql | JWT | HTTP/GraphQL |
Every project has two keys: anon (public, embedded in client code, limited by RLS) and service_role (secret, bypasses RLS, for server-side use only). Both are JWTs with different role claims that PostgreSQL uses to determine access level.
The full picture: how every Supabase service connects to every other service. PostgreSQL is the central hub — every service either reads from it, writes to it, or both. The gateway routes, GoTrue authenticates, and all authorization happens at the database level via RLS.
graph TD
subgraph External["External"]
CLIENTS["Client Apps"]
OAUTH["OAuth Providers"]
S3EXT["S3 / R2"]
AI["AI APIs
(OpenAI, etc.)"]
end
subgraph Gateway["Gateway Layer"]
KONG["Kong / Envoy"]
end
subgraph Services["Service Layer"]
REST["PostgREST"]
GOTRUE["GoTrue"]
RTSERV["Realtime"]
STORAGE["Storage API"]
EFUNC["Edge Functions"]
PGMETA["postgres-meta"]
PGGQL["pg_graphql"]
end
subgraph PGCore["PostgreSQL"]
DB["Tables & Views"]
AUTHSCH["auth Schema"]
STORSCH["storage Schema"]
VEC["pgvector"]
RLSENG["RLS Engine"]
LOGREP["Logical Replication"]
PGNET["pg_net"]
PGCRON["pg_cron"]
end
CLIENTS --> KONG
KONG --> REST
KONG --> GOTRUE
KONG --> RTSERV
KONG --> STORAGE
KONG --> EFUNC
KONG --> PGMETA
KONG --> PGGQL
REST --> DB
REST --> RLSENG
GOTRUE --> AUTHSCH
GOTRUE --> OAUTH
RTSERV --> LOGREP
STORAGE --> STORSCH
STORAGE --> S3EXT
EFUNC --> REST
EFUNC --> AI
PGMETA --> DB
PGGQL --> DB
PGNET --> EFUNC
PGCRON --> PGNET
DB --> RLSENG
AUTHSCH --> RLSENG
style KONG fill:#162a21,stroke:#48bb78,color:#fff
style REST fill:#0d1a14,stroke:#3ecf8e,color:#fff
style GOTRUE fill:#0d1a14,stroke:#f56565,color:#fff
style RTSERV fill:#0d1a14,stroke:#f5a623,color:#fff
style STORAGE fill:#0d1a14,stroke:#9f7aea,color:#fff
style EFUNC fill:#0d1a14,stroke:#3fc5f0,color:#fff
style PGMETA fill:#0d1a14,stroke:#8faa9b,color:#fff
style PGGQL fill:#0d1a14,stroke:#e879a0,color:#fff
style DB fill:#111f19,stroke:#336791,color:#fff
style AUTHSCH fill:#111f19,stroke:#f56565,color:#fff
style STORSCH fill:#111f19,stroke:#9f7aea,color:#fff
style VEC fill:#111f19,stroke:#e879a0,color:#fff
style RLSENG fill:#111f19,stroke:#336791,color:#fff
style LOGREP fill:#111f19,stroke:#f5a623,color:#fff
style PGNET fill:#111f19,stroke:#3fc5f0,color:#fff
style PGCRON fill:#111f19,stroke:#f5a623,color:#fff
| Source | Target | Protocol | Purpose |
|---|---|---|---|
| PostgREST | PostgreSQL | libpq (TCP) | Query execution with RLS context |
| GoTrue | PostgreSQL | libpq (TCP) | User CRUD, session management |
| Realtime | PostgreSQL | Logical replication | WAL streaming for CDC events |
| Storage API | PostgreSQL | libpq (TCP) | Object metadata + bucket policies |
| Storage API | S3 / R2 | S3 API (HTTPS) | Binary object storage |
| Edge Functions | PostgREST | HTTP (internal) | Database access via service role |
| pg_net | Edge Functions | HTTP (outbound) | Database webhooks & triggers |
| GoTrue | OAuth Providers | HTTPS / OAuth 2.0 | Identity federation |
Supabase services are at different maturity levels. Core services (Database, Auth, PostgREST) are battle-tested and GA. Newer capabilities like Vectors and Branching are stabilizing rapidly.
| Service | Status | Language | Open Source | Key Metric |
|---|---|---|---|---|
| PostgreSQL | STABLE | C | PostgreSQL License | v15+ with 50+ extensions |
| PostgREST | STABLE | Haskell | MIT License | Auto-generated from schema |
| GoTrue (Auth) | STABLE | Go | MIT License | 30+ OAuth providers |
| Realtime | STABLE | Elixir | Apache 2.0 | CDC + Broadcast + Presence |
| Storage | STABLE | Node.js / TypeScript | Apache 2.0 | S3-compatible + transforms |
| Edge Functions | GA | TypeScript (Deno) | Apache 2.0 | V8 isolates, global edge |
| pgvector | STABLE | C | PostgreSQL License | HNSW + IVFFlat indexes |
| pg_graphql | GA | Rust | Apache 2.0 | GraphQL from schema |
| Branching | BETA | Go | Hosted only | Preview environments |
| Supabase AI | BETA | TypeScript | Apache 2.0 | Inference API gateway |
Every core Supabase service can be self-hosted via Docker Compose or Kubernetes. The official supabase/supabase repository includes a complete docker-compose.yml with all services pre-configured. The hosted platform adds managed infrastructure, automatic backups, point-in-time recovery, and a web dashboard (Studio).