Is Supabase Encryption Strong Enough for Sensitive Data?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Supabase encrypts all database files, WAL logs and backups with AES - 256 automatically.
• All network traffic to Supabase services must use TLS 1.2 or higher; verify-full is the recommended sslmode.
• The Supabase Vault stores secrets using libsodium AEAD; keys live outside the database and are never exposed in SQL.
• To avoid leaking plaintext secrets, disable statement logging for tables that use Vault.
• Supabase’s encryption meets SOC 2 Type 2, ISO 27001 and GDPR requirements, and supports HIPAA once you add the Business Associate Agreement.

Does Supabase encrypt data at rest?

Yes, Supabase encrypts every piece of data on disk, including tables, indexes, WAL logs and daily backups, using AES - 256. The encryption is applied at the storage layer, is transparent to the developer and cannot be turned off.

The platform manages the encryption keys internally. When you create a project a per - project root key is generated and stored in Supabase’s secured backend services. This key is used for all at - rest encryption operations and is never written to the database itself.

How does Supabase protect data in transit?

All connections to Supabase services (PostgREST, Realtime, Storage, Auth) require TLS 1.2 or higher. The PostgreSQL client can be configured with any standard sslmode option; the strongest setting is verify-full, which validates both the server certificate authority and the hostname.

-- Example connection string with strict TLS verification
psql "postgresql://USER:PASS@db.supabase.co:5432/DBNAME?sslmode=verify-full"

Projects can also enable SSL enforcement in the dashboard, which forces all Postgres connections to use TLS and triggers a brief database reboot.

What is Supabase Vault and how does it encrypt secrets?

Supabase Vault is a built - in secret store that provides a table vault.secrets and a view vault.decrypted_secrets. Secrets are encrypted using Authenticated Encryption with Associated Data (AEAD) based on libsodium. The encryption keys are never stored in the database; only a key - identifier is persisted.

When you insert a secret:

INSERT INTO vault.secrets (name, secret) VALUES ('api_key', 'my - super - secret');

the value is encrypted client - side and written as bytea. Decryption happens only when you query the view:

SELECT * FROM vault.decrypted_secrets WHERE name = 'api_key';

The per - project root key lives in Supabase’s backend and is never exposed to the project owner - Vault is designed so decryption only happens inside the vault.decrypted_secrets view, not by extracting the key itself.

Can I encrypt arbitrary columns with Supabase?

Supabase previously offered Transparent Column Encryption (TCE) via pgsodium for this, but it's now pending deprecation and no longer recommended due to its operational complexity and misconfiguration risk. For column - level secrets, store them in Vault instead and reference them from your application, or apply encryption at the application layer before the value reaches Postgres.

How should I protect my secrets from accidental logging?

By default Supabase logs all SQL statements, which would expose plaintext secrets inserted into vault.secrets. To mitigate this risk, disable statement logging for projects that use Vault:

ALTER SYSTEM SET log_statement = 'none';
-- Then restart the project for the change to take effect

This ensures that INSERT and UPDATE statements containing raw secret values are not written to the logs.

Does Supabase meet compliance standards?

Supabase’s encryption controls satisfy major regulatory frameworks, including SOC 2 Type 2, HIPAA (with a Business Associate Agreement), ISO 27001 and GDPR. The combination of AES - 256 at rest, TLS 1.2+ in transit, and AEAD - based secret storage helps organizations meet data - protection requirements.

How does Supabase compare to a DIY encryption setup?

What steps should I take to harden Supabase encryption?

1. Enable SSL enforcement in the project settings to force TLS for every connection.
2. Use sslmode=verify-full in all client connection strings.
3. Store any sensitive configuration values in vault.secrets or encrypt columns with TCE.
4. Disable statement logging (ALTER SYSTEM SET statement_log = 'none';).
5. If you suspect the project itself is compromised, treat it as a full incident (rotate all credentials, review access logs) rather than attempting to rotate the root key directly - it isn't exposed for that.
6. Regularly review the compliance dashboard in the Supabase console to ensure controls remain active.

What if I need to migrate Vault data to another platform?

Because the root key is never exposed, migrating Vault - encrypted data means decrypting each secret through vault.decrypted_secrets while still on Supabase and re - encrypting it in your new destination - not extracting and reusing the underlying key.

For teams that already use Decloak, the free scan will surface any publicly readable Supabase tables, misconfigured SSL settings, or missing Vault encryption, giving you an early warning before a breach.