Supabase for professional secrecy holders

Does Supabase need to be operated or migrated for a law firm, medical practice or another organisation handling professional secrets? Assess the Supabase operating model.

Supabase is attractive for AI-generated applications, portals and internal business software because PostgreSQL, authentication, storage, realtime, APIs and functions come together in one platform. That breadth also makes assessment more demanding for professional secrecy holders: a database location alone does not describe where identities, files, logs and server-side functions are processed.

A useful assessment starts with the application and treats Supabase as a complete platform.

Which Supabase components may be involved?

An application may store only case identifiers in PostgreSQL while full documents live in Storage. Conversely, database functions may process sensitive content even when the frontend only displays a shortened version.

Supabase Cloud or self-hosting?

The two models have different responsibility boundaries.

Supabase Cloud

The platform provider operates the environment it supplies. Edition, region, capabilities, support path, service providers and agreements need to be assessed for the intended processing. The Supabase documentation on its security boundary explicitly notes that controls within the Supabase product do not automatically transfer to environments outside that boundary.

Self-hosted Supabase

The open-source stack runs on customer-controlled or managed infrastructure. This creates different choices for location, networking and participating providers. It also gives the operator additional responsibility for:

• hardening and secrets
• updates across Supabase components
• PostgreSQL and platform upgrades
• monitoring and alerting
• database and storage backup
• recovery and scaling
• SMTP, domains and external services

The official self-hosting documentation explains that self-hosting does not provide the same managed feature set as Supabase Cloud. Required cloud capabilities need to be replaced in the target operating model.

Self-hosting is therefore not an automatic compliance switch. It expands both control and operational responsibility.

RLS and tenant separation

Browser and mobile applications often access the Supabase Data API directly. Row Level Security can constrain access at row level. For client or patient data, review at least:

• Is RLS enabled on every exposed table?
• Are there policies for select, insert, update and delete?
• Are anonymous and authenticated roles separated?
• Can users modify their tenant or organisation assignment?
• Are views, functions and RPC calls protected appropriately?
• Which components use service_role or other privileged roles?
• Do Storage rules and database permissions align?

Test policies against real user journeys. Reading SQL alone can miss interactions between JWT claims, views and server-side functions.

Authentication is more than a user table

Supabase Auth processes identities, sessions and tokens. The target model should cover:

• permitted login methods and OAuth providers
• MFA requirements
• redirect URLs and domain changes
• SMTP and auth-email content
• token and secret lifetime and rotation
• account suspension, deletion and export
• administrative user management

During migration, password hashes, provider links or existing sessions may need special handling. The plan should state whether users can be transferred seamlessly or need to sign in again.

Storage, functions and external data paths

Storage buckets and Edge Functions often create the largest blind spots.

For Storage, assess:

• public and private buckets
• signed URLs and their lifetime
• object paths and tenant separation
• file types, size limits and malware scanning
• metadata and actual objects in backup

For Functions, assess:

• secrets and API keys
• outbound connections
• webhooks and external recipients
• request and response logging
• deployment and versioning
• error behaviour and retries

A Function can send protected information to an external service even while database and Storage run entirely within a controlled environment.

Backup and recovery

A PostgreSQL dump does not restore all of Supabase. A dependable concept covers:

1. database schema, roles, data and required extensions
2. Storage objects and associated metadata
3. Functions and their deployment state
4. configuration and secrets under a separate protection model
5. auth, SMTP, domain and provider configuration
6. a documented restore into an empty target environment

Retention and deletion need to include additional copies. Back up Supabase completely explains the technical layers in depth.

Migration into a controlled target model

An existing Cloud, Lovable or Firebase backend should not be switched in the first run. Use a controlled path:

1. Inventory components and dependencies.
2. Prepare the target environment with networking, auth, backups and monitoring.
3. Transfer database, Storage, Functions and configuration in a rehearsal.
4. Test RLS and business user journeys in the target environment.
5. Define cutover, maintenance window and rollback point.
6. Perform production cutover and complete documented acceptance.

After migration, the development team can continue working on the application with its familiar AI and development tools. Git pushes are connected to the new Supabase environment through the agreed build and deployment path. Depending on criticality, this includes separate staging and production environments, approvals, database-migration checks and rollback.

The Supabase migration checklist covers the general sequence. WZ-IT offers a technical Supabase migration from EUR 3,490 excluding VAT; the actual scope is assessed before a concrete proposal.

Related WZ-IT services

• The Supabase migration from EUR 3,490 excluding VAT is an independent starting point for Supabase Cloud, Firebase, Lovable and other source systems. The starting price does not define a fixed service scope.
• Managed Supabase covers installation, managed hosting and ongoing operations for the target platform.
• The AI Code & Production Readiness Audit assesses the application connected to Supabase, including auth, RLS, secrets and deployment.
• The Section 203 Managed Cloud for Supabase adds the dedicated operating model for professional secrets to these generally available services.

Sources

• Supabase documentation: architecture
• Supabase documentation: self-hosting
• Supabase documentation: Row Level Security
• Supabase documentation: security and compliance boundary
• German Criminal Code, Section 203