Postgres is the center of a much larger backend
Supabase starts with a dedicated Postgres database and layers common application services around it. PostgREST produces a REST API, pg_graphql adds GraphQL, Auth handles identities and sessions, Realtime broadcasts database changes, Storage manages files, and Edge Functions run server-side code. Studio gives developers a dashboard over those parts. The combination can replace weeks of initial backend assembly for a web or mobile product that already fits SQL.
The source repository shows how broad that promise is. Our commit 310b29c checkout contained 16,962 files, roughly 999,060 lines of source, and occupied 761.8 MB before dependencies. It is a Turborepo containing websites, documentation, Studio, design systems, shared packages, and deployment assets. The individual infrastructure services often live in their own repositories, so this monorepo is both product surface and integration point rather than the complete implementation of every running component.
Hosted Supabase avoids the 2,934 MB contributor setup
A hosted project can be created without installing this repository. That is the product's easiest and most convincing route: Supabase operates the database and surrounding services, while an application uses a client library or generated API. The open-source checkout matters for transparency, contribution, local development, and self-hosting, but it should not be confused with the normal first step for a managed customer.
Our source install added 3,094 pnpm packages in 88 seconds and consumed 2,934 MB. Contributors also need the Node.js and pnpm versions pinned by the repository, make, local environment files, and Docker for Studio. The developer guide exposes separate commands for the marketing site, docs, and dashboard. A person fixing one interface should scope the workspace instead of treating the root command as a small application build.
What happened when we ran it
Our sandbox installed Supabase successfully in 88 seconds on 3 CPUs with 8 GB of RAM. The environment was a fresh unprivileged Debian container based on Node 22, with no secrets. Installation completed, but the root build exited with code 1 after 36 seconds. Turbo recorded 1 successful task out of 9 and named docs#build:federated-content as the failed command.
The log tail also listed lifecycle failures for library, learn, design-system, and studio builds after the federated-content failure. It does not show the underlying error that caused that task to exit, so assigning a network, credential, or code cause would be guesswork. The developer guide says federated documentation can fetch markdown from external repositories at build time, which explains what the task does, not why our particular run failed.
No tests script or target was available, so our harness skipped tests. The root had 48 CI workflow files but no tests directory. Those repository signals show extensive automation, yet they do not supply a passing test result for commit 310b29c in our environment. The honest outcome is mixed: dependency installation worked, the full build did not, and there was no root test command for us to report.
Self-hosting means operating more than Postgres
The official Docker Compose setup includes Studio, Envoy, Auth, PostgREST, Realtime, Storage, imgproxy, postgres-meta, PostgreSQL, Edge Runtime, Logflare, Vector, and Supavisor. That list is the clearest reason to reject casual self-hosting. You gain control over data and deployment, but you also inherit service health, image versions, logs, network policy, database maintenance, and compatibility across moving parts.
Supabase labels the default self-hosted configuration insecure for production. Operators must replace default passwords and secrets, review CORS, restrict the network, place a secure proxy where appropriate, and establish backups. Updates begin with a database backup and include dry-run, pull, recreate, conflict, and rollback guidance. Community support covers self-hosted installations. A team that needs guaranteed operational help should compare that boundary with the managed service before committing.
Row-level security is part of application correctness
Generated browser-facing APIs make database authorization unusually important. Supabase relies on Postgres roles, JWT claims, and row-level security policies to decide which rows a caller may read or change. That can keep policy close to the data and work across REST, GraphQL, and realtime paths. It can also expose data if a team creates tables and postpones policy design until after the client application is working.
A serious evaluation should model at least 2 roles and test each policy with real queries, storage objects, and realtime subscriptions. Service-role credentials need a separate server-side boundary because they can bypass ordinary client restrictions. Supabase does not remove backend security work; it relocates a meaningful share into SQL and database configuration. Teams comfortable reviewing migrations and query plans will have a better experience than teams treating the dashboard as a no-code permission system.
Current activity supports the platform, not every deployment choice
GitHub showed 108,443 stars, 1,037 open issues and pull requests, and a last push on 2026-08-27. The combined open count should not be read as 1,037 bugs. Developer Update v1.26.08 was published on 2026-08-07 and covered managed features, betas, an alpha data pipeline, observability, encryption integration, and API changes. That pace indicates active product work and creates a reason to read changelogs before upgrading.
Supabase is easiest to recommend as a managed Postgres platform with useful services attached. The database remains accessible through standard SQL, and the application features save real assembly work. Our failed 36-second build and 2,934 MB dependency tree make the source contribution path look heavier than the hosted onboarding. For self-hosting, compare the operational list against a plain Postgres service. If you do not need Auth, Realtime, Storage, Studio, and functions together, the smaller system is easier to own.