Supabase

Model tables before exposing them. Name data owners, define migrations, choose primary keys and relationships, and decide which operations each user role may perform. PostgreSQL roles and row-level security policies deserve the same review as application code because they determine whether a request may read, insert, update, or delete a record. Keep policies small enough that another engineer can test and explain them.

Use realistic test users for every policy. Test an allowed read, an allowed write, a cross-tenant attempt, an attempt to alter ownership fields, and an administrator-only operation. Include API behaviour and direct database paths where the architecture allows them. A policy that works in a console under an elevated credential proves very little about a browser client.

Generated API endpoints should be placed behind an intended network and authentication boundary. Keep privileged secrets on trusted server components, rotate them through a controlled secret store, and record which internal service owns each credential. Do not place a privileged service secret in a mobile build, public browser code, or a copyable dashboard configuration.

Authentication configuration affects account creation, sessions, redirects, and recovery. Choose approved identity flows and test them from the actual browser origins and network paths that users will use. Keep an emergency administration procedure, but do not make a shared break-glass account the usual support route. Offboarding needs to remove access from the identity path and any application roles derived from it.

Storage needs its own authorisation review. List bucket purposes, allowed file types, maximum sizes, malware or content inspection responsibilities, retention, and who can read each object. Test object access with an ordinary user, another tenant's user, and a server-side component. File metadata and signed access paths can disclose information even when the object itself is protected.

Realtime workload depends on subscriptions, event rate, client reconnects, and database changes. Measure the intended use case rather than assuming a chat-like workload. Set limits and observe behaviour when a client reconnects or a downstream dependency fails. If the application does not need immediate events, simpler request-response paths often reduce the operating surface.

Self-hosting adds responsibility for PostgreSQL, Supabase service configuration, network access, object storage where used, backups, monitoring, and updates. Follow the current self-hosting architecture and release guidance for the selected version. Keep an architecture record that shows databases, service endpoints, storage, identity, ingress, and the system that supplies secrets. This keeps troubleshooting from becoming a search across undocumented containers.

Back up database data and test the restore path alongside files and configuration. A database-only restore may leave records pointing at missing objects; an object-only recovery may restore files with no authorisation context. Set recovery objectives with the application owner, test in isolation, and record the accepted loss window and steps that still require manual work.

Run upgrades through a representative environment when possible. Confirm migrations, API behaviour, row-level security tests, login, uploads, and any realtime use. Pin the versions that passed the test, read version-specific compatibility notes, and name the person who decides whether an issue requires rollback or a corrective release.