Searchable field-level encryption on Supabase with CipherStash

The CipherStash integration for Supabase is now available.

CipherStash is a Data Level Access Control (DLAC) platform for applications built on Postgres. DLAC extends traditional access control, which typically operates at the row or table level, down to individual encrypted values, so policies are enforced at decryption rather than at the query layer.

With CipherStash, teams can encrypt sensitive fields at the application layer with a unique key per value, run searches and joins against encrypted data without decrypting it, and keep keys under their own control through ZeroKMS, CipherStash's zero-knowledge key management service. Because keys never leave your control, neither CipherStash nor Supabase can access your plaintext data.

The Supabase integration enables teams to add field-level encryption to any Supabase project using the encrypted Supabase SDK wrapper without changing the schema. Setup is one CLI command: npx stash init --supabase

.

Why this matters for regulated workloads#

Most teams that handle regulated data end up choosing between two bad options:

**Use traditional field-level encryption:**Encrypted values are random bytes as far as Postgres is concerned.WHERE email = ?

matches nothing, indexes stop working, and joins fail. The only way to search is to pull every row, decrypt it in your app, and filter in memory. Teams end up building expensive workarounds or dropping the feature entirely.**Skip encryption:**The application stays fast, but when a breach happens, plaintext sensitive data is the first thing auditors ask about.

CipherStash gives you a third option.

DLAC extends access control down to individual encrypted values. Encryption happens inside your application before data reaches the database. Each value is stored as a single JSON payload containing the ciphertext alongside Searchable Encrypted Metadata (SEM). That is enough for Postgres to filter, sort, and join, but not enough to recover the original value. Queries are converted to SEM on the way in, Postgres matches against the stored SEM, and only the ciphertexts your application is authorized to decrypt come back. Every encrypted value carries a policy stating who can read it and under what condition. That policy is enforced at decryption, not at the query layer.

For teams under HIPAA, GDPR, or SOC 2, you keep Postgres, Supabase, and search, with a shorter compliance review and a smaller breach surface.

How the integration works#

Add DLAC to your existin