Is data in Supabase encrypted?

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, indexes, WAL logs, and backups with AES‑256 full‑disk encryption (at rest).
• All network traffic to Supabase services is protected by TLS 1.2+ (in transit).
• For highly sensitive values you can use Supabase Vault, which stores data with AEAD encryption and keeps the root key outside the database.
• These encryption mechanisms are always‑on, cannot be disabled, and satisfy SOC 2, ISO 27001, HIPAA, and GDPR requirements.

Does Supabase encrypt data at rest?

Yes, Supabase encrypts every piece of stored data-including database files, indexes, WAL logs, and daily backups-with AES‑256 full‑disk encryption provided by the underlying cloud provider (AWS, GCP, Azure). The encryption is always enabled and the keys are managed by the cloud provider, never by your project.

How is traffic to Supabase protected while in transit?

All requests to Supabase’s API, Auth, Realtime, Storage, and Postgres endpoints use TLS 1.2 or higher. You can enforce the strongest verify-full mode for Postgres connections to ensure certificate verification. TLS certificates are rotated automatically by Supabase.

What if I need to store secrets like API keys inside the database?

Supabase offers Vault, a server‑side secret store that encrypts data with Authenticated Encryption with Associated Data (AEAD) built on libsodium. The encrypted values are stored on disk, and a special view (vault.decrypted_secrets) decrypts them only at query time. The root encryption key is generated per project and kept in Supabase’s secured backend, separate from the database.

Can I encrypt individual columns in my tables?

Yes. Supabase supports Transparent Column Encryption (TCE) via the pgsodium extension. You can create additional encryption keys with pgsodium.create_key(). These keys are derived from the same per‑project root key used by Vault and also live outside the database.

How do these encryption layers map to compliance standards?

The default at‑rest AES‑256 encryption and TLS in‑transit satisfy the data‑protection requirements of SOC 2, ISO 27001, HIPAA, and GDPR. Vault adds an extra layer for secrets, helping you meet stricter secret‑management controls in those frameworks.

Comparison of Supabase encryption features

How to verify encryption is working for my project

1. Check the dashboard – Supabase’s security page lists “Data Encryption” as enabled for your project.
2. Inspect TLS – Use curl -v https://<your-project>.supabase.co and confirm TLSv1.2 or higher in the handshake.
3. Test Vault – Insert a secret into vault.secrets and query vault.decrypted_secrets; the raw value never appears in the underlying tables.
4. Enable TCE – Run SELECT pgsodium.create_key('my_key'); and encrypt a column with pgsodium.crypto_secretbox(... ) to see encrypted ciphertext stored on disk.

Bottom line

Supabase provides default encryption‑at‑rest (AES‑256) and encryption‑in‑transit (TLS 1.2+). For ultra‑sensitive data, you can add Vault or Transparent Column Encryption, both of which keep the encryption keys outside the database. All of these mechanisms are always‑on, meet major compliance standards, and require no extra configuration to benefit from the baseline protection.