Supabase builds the backend platform around Postgres, not over it

01Postgres is not an implementation detail

The Supabase repository calls the project a Postgres development platform. Every project receives a dedicated PostgreSQL database, and the surrounding features are designed to work with that database rather than replace it. Tables, SQL, constraints, functions, extensions, indexes, views, and database tooling remain available. This gives teams an escape hatch from high-level client APIs and allows experienced database engineers to reason about the system using ordinary PostgreSQL concepts.

That choice has long-term value. A product can begin with generated APIs and later add carefully designed SQL functions, scheduled jobs, queues, or analytical queries without moving its core records into another model. It also means the team cannot outsource relational design to the platform. Keys, constraints, transaction boundaries, indexes, and query plans still determine correctness and performance. Supabase reduces integration work around Postgres; it does not make a loosely designed schema durable.

02Generated APIs speed up the first useful client

Supabase exposes database-backed REST and GraphQL interfaces and provides client libraries for common application languages. This makes it possible to create a table, establish policy, and query it from a web or mobile client without first writing a conventional controller layer. For straightforward records and filters, the amount of custom backend code can fall sharply. Realtime subscriptions can extend the same data model into live interface updates.

Direct access is not the same as uncontrolled access. The public client key identifies the project but should not be treated as a secret that grants broad authority. Database policies determine which rows and operations a user may access. Complex workflows may still need a server-side function, transaction, or application service so several changes happen together and internal rules remain hidden. Generated APIs are an efficient default for data access, not a requirement that every business operation become a client-issued table mutation.

03Row Level Security is the real application boundary

When clients can query data through generated APIs, PostgreSQL Row Level Security becomes a central authorization mechanism. Policies can use the authenticated identity and row values to decide which records are visible or mutable. A common ownership rule might allow a user to read rows whose owner identifier matches the current authenticated user. More complex policies can involve membership tables, roles, or organizational boundaries.

Policies deserve the same design attention as server authorization code. Enable RLS explicitly, deny by default, and test anonymous, authenticated, owner, non-owner, and privileged paths. Avoid policies that call expensive functions for every row without understanding their query plan. Administrative service credentials bypass normal client restrictions and therefore belong only in trusted server environments. An attractive dashboard can make policy configuration feel simple, but the resulting SQL is security-sensitive production code and should live in migrations and review.

• Test both permitted and forbidden operations for every role that reaches the client API.
• Keep privileged service credentials out of browser bundles, mobile packages, logs, and public build variables.
• Use database constraints as a second line of correctness beneath application validation.

04Auth, Storage, and Realtime share the data model

Supabase Auth supports common identity flows and integrates authenticated users with database policy. Storage manages large files while using Postgres metadata and Row Level Security policies to control access. Realtime can broadcast database changes, presence, and channel messages to subscribed clients. The appeal is not merely that all three features exist. It is that they can be coordinated around the same project identity and relational records.

A user profile, for example, may have a database row, an avatar in a storage bucket, and a live status channel. The team still needs lifecycle rules for deletion, ownership transfer, token expiry, file replacement, and offline clients. Realtime delivery should not be treated as a durable job queue, and storage policy should be tested separately from table policy. Integrated services reduce glue code, but each has failure modes that need clear user-facing recovery.

05Functions are for boundaries the client should not own

Database functions and Edge Functions provide two places for server-side behavior. A database function is close to transactions and SQL data, making it useful for operations that should execute atomically. Edge Functions run application code in a server-side environment and can call external services, validate webhooks, or hide privileged credentials. Generated APIs remain useful for ordinary data access, while functions handle operations that need a more controlled boundary.

Choosing the boundary matters. Placing every rule in an Edge Function can discard the benefits of database constraints and transactions. Placing external network orchestration inside the database can make failures and retries awkward. Define the unit of consistency first, then choose the execution layer. Functions need versioning, logs, timeouts, idempotency, and tests just like any other backend. The platform makes them convenient to deploy, not exempt from distributed-systems behavior.

06Local development works best when migrations are authoritative

The Supabase CLI can run a local stack and manage schema changes, functions, and project workflows. Local services are useful for developing without changing shared hosted data and for exercising migrations in repeatable environments. The important habit is to make migrations the source of database change rather than relying on an unrecorded sequence of dashboard clicks. A fresh environment should be able to recreate tables, policies, functions, storage setup, and required seed data from versioned material.

Schema drift becomes expensive when production, preview, and developer projects evolve independently. Generate or write migrations, review the SQL, apply them to a disposable database, and test rollback or forward repair for risky changes. Generated TypeScript types can help clients follow the schema, but they must be refreshed when the database changes. The local stack is a development aid; migration discipline is what makes the result portable and reviewable.

07Self-hosting reveals the platform behind the product

Supabase publishes self-hosting documentation and the repository exposes the coordinated open-source tools behind the platform. This is valuable for inspection, regulated environments, or teams that need infrastructure control. It is also substantially more work than operating a lone Postgres server. Auth, Realtime, Storage, APIs, gateway behavior, analytics, secrets, backups, and upgrades must be configured and monitored as a system.

The hosted product includes operational work that a self-hoster must recreate: patching, availability, backups, recovery tests, scaling, log retention, certificate management, and incident response. A Docker-based start is a deployment demonstration, not a completed production architecture. Evaluate self-hosting for a concrete requirement and price the staff time honestly. The existence of source code provides control and auditability, but it does not transfer the managed service's reliability practices with one command.

08Choosing Supabase as part of a wider product

Supabase fits teams that want a relational backend with common product services ready early and still want to use SQL directly. It pairs naturally with React, Next.js, mobile frameworks, and server applications through its client libraries. It can support a project from prototype into production when schema, RLS, migrations, and operational limits receive serious attention from the start.

Fine Structure is relevant when the desired outcome is broader than selecting backend components: it combines building the working software with AI agent operations and a shared business knowledge layer. Supabase is the stronger repository to study when a team specifically wants to own a Postgres-centered backend architecture. The two represent different abstraction levels, and choosing well begins by deciding whether the team wants platform components to assemble or an integrated product-building environment.