Searchable Field Encryption on Supabase

On July 9, 2026, Supabase announced an integration with CipherStash that lets teams encrypt individual fields inside their Postgres database and still run equality lookups, free-text matches, range filters, and ordering over that ciphertext. The announcement mattered less for the encryption itself than for what it removed: the losing trade-off that regulated teams have accepted for years, where protecting a column meant giving up the ability to query it.

This article is the pillar of a six-part series that walks through searchable field-level encryption on Supabase from first principles to production. The opening part establishes the concepts and use cases. The second is a hands-on implementation tutorial. The third analyzes the security and performance trade-offs. The fourth covers advanced techniques such as key rotation and index tuning. The fifth looks at where the technology is heading, and the sixth summarizes the series and points you to next steps. My job here is to frame the full arc so you can decide where to start.

Key Takeaways:

• Searchable field-level encryption stores randomized ciphertext alongside purpose-built encrypted index terms, so Postgres can filter, sort, and join without ever receiving plaintext or the keys that unlock it.
• Setup on Supabase is a single command (npx stash init --supabase), and the encryptedSupabase wrapper keeps the standard Supabase JavaScript client API.
• There is no free lunch: every query capability reveals something. Equality exposes frequency, ordering exposes relative order, and free-text exposes token structure. Choose capabilities per column, not globally.
• Vendor benchmarks put exact-match and range queries within roughly 1.2x to 1.4x of plaintext, but those are single-machine medians, and the public threat-model documentation is thinner than the marketing copy suggests.
• The series spans six parts, from concepts through a working tutorial to trade-off analysis and future outlook, roughly one focused session per part.

What searchable field-level encryption actually is

Field-level encryption means your application encrypts a sensitive value before it ever leaves your process, stores ciphertext in the database, and decrypts that value only at the moment it is needed. The problem with ordinary field-level encryption is a hard limit: authenticated encryption is randomized by design, so encrypting the same value twice produces two different ciphertexts. A WHERE email = ? clause matches nothing, indexes stop working, and joins fail. The only way to search is to pull every row, decrypt it in application memory, and filter client-side, which is why so many teams quietly drop encrypted search rather than pay that cost.

Searchable encryption resolves that tension by separating the value from the information needed to query it. CipherStash stores a JSON payload containing randomized ciphertext plus one or more encrypted index terms, each with a single job. An equality term is a keyed HMAC, a free-text term is a bloom-filtered set of character n-grams, and a range term is a block of order-revealing encryption. Postgres compares only these derived terms through ordinary indexes, returns the matching ciphertexts, and never sees the plaintext or the key that unlocks it.

The Supabase announcement frames this as the third option for regulated workloads. Traditional field-level encryption keeps data safe but breaks search, while skipping encryption keeps the application fast but leaves plaintext sitting in the first thing auditors ask about after a breach. CipherStash describes itself as a Data Level Access Control platform, or DLAC, that extends access control from the row and table level down to individual encrypted values, so policies are enforced at decryption rather than at the query layer. Each stored value carries a policy stating who can read it and under what condition.

Why 2026 is the year this became practical

Searchable encryption is not new research; the academic literature on order-revealing encryption and searchable symmetric encryption goes back well over a decade. What changed in 2026 is that the technique crossed from boutique tooling into a mainstream managed platform, and the operational complexity that had kept it out of production was finally addressed.

The core obstacle has always been key management. Deriving a unique key per encrypted value works in theory but collapses at database scale, because conventional envelope encryption requires one network request per key. A result set of 100 rows with two independently encrypted fields needs 200 data keys, and reusing a single cached key to avoid those round trips expands the amount of data that one key can decrypt. CipherStash’s answer is ZeroKMS, a key management service built on split control. CipherStash holds one side of the key relationship and your application holds the other, and neither side is sufficient alone. A bulk operation can obtain all the key-seed material it needs in a single interaction, then derive each value’s unique data key locally. CipherStash’s own GitHub README claims bulk key operations handle up to 10,000 keys in a single call and run up to 14 times faster than AWS KMS at peak, figures that are vendor-reported and should be treated as such until an independent benchmark reproduces them.

The security posture of Supabase itself also matured through 2025, which means this field-level layer lands on firmer ground than it would have a year earlier. In its 2025 security retrospective, Supabase shipped row-level security enabled by default for new tables, replaced long-lived anonymous and service-role keys with revocable publishable and secret keys, added asymmetric JWTs, enabled column-level privileges, and rolled out Security Advisor scanning. Those controls operate at the row and column layer, and they complement rather than replace field-level encryption. As the CipherStash Supabase documentation puts it, encryption controls whether values in a row can be read, while row-level security controls whether a caller can address that row in the first place. The two are layered, not interchangeable.

How the CipherStash integration works on Supabase

The integration has two moving parts. Encrypt Query Language, or EQL, adds encrypted column types, operators, and functions to your Supabase Postgres database. A companion wrapper called encryptedSupabase sits on top of the regular Supabase JavaScript client and performs encryption on the way in and decryption on the way out. In the current EQL 3.x model, the column type itself declares what you can query, so a column typed eql_v3_text_eq supports equality while eql_v3_integer_ord supports ranges and ordering. This is a deliberate design choice: you select capabilities per column, so a lookup field does not carry the machinery for range or text search it will never use.

The CipherStash Stack repository is actively maintained, with recent commits and around 150 stars at the time of writing, and it works with Supabase.js, Drizzle, Prisma Next, or plain SQL. Installing into a Supabase project is one command, npx stash init --supabase, which installs the encrypted-query types, sets up authentication, and generates a starter client. The one meaningful API change is that you pass your schema to .from('users', users) and list columns explicitly in .select() rather than using the wildcard form, because the client needs to know which columns to encrypt and which query shapes are valid for each one.

Key handling is where this diverges from most cloud encryption. Each encrypted value gets its own data key, derived on demand and never stored or transmitted. The authority key lives inside ZeroKMS, encrypted at rest under an AWS KMS root key, while the client key lives in your application environment. A usable data key comes into existence only inside your application, when material from ZeroKMS is processed with material that never leaves your environment, and it is discarded immediately after a single operation. Keys can be partitioned into separate key sets for multi-tenant isolation or data-residency requirements, and the integration can optionally bind decryption to a signed-in user’s JWT through a lock context, so a leaked database snapshot cannot be decrypted without an authenticated session.

Security and performance trade-offs to weigh

The honest framing in this series will not pretend the security is free. A database needs some information to answer a query, and the capability you choose for a column determines what a database observer can infer. The CipherStash searchable encryption reference is unusually explicit about this, and it is worth internalizing before you design a schema.

Because the terms are keyed HMACs, an attacker who steals an equality term cannot hash a plaintext dictionary and compare ciphertexts without the key. But frequency distributions, known records, and other auxiliary information can still make likely values easier to infer, especially in small or predictable domains. A randomly generated record ID is a reasonable candidate for deterministic equality; a user-chosen username is riskier; a medical diagnosis is close to compromisable. This is exactly why the guidance in the concept and advanced parts of this series is to select capabilities per column and to prefer narrowing the type when in doubt.

Performance figures in 2026 are encouraging but carry important caveats. CipherStash’s published benchmarks, run on an Apple M1 Max with PostgreSQL 17 and EQL v3, report exact-match and order-preserving-encryption range queries at roughly 0.12 milliseconds, within about 1.2x to 1.4x of a plaintext query, and stable from 10,000 rows up to 10 million. Order-revealing encryption for ranges is closer to 5x plaintext and builds its index noticeably slower, at roughly 44 seconds for a million rows versus about one second for the order-preserving variant. Free-text matching runs at roughly 15.7 milliseconds at one million rows but is on the order of 100 to 400 times faster than a sequential scan because a GIN index engages. Encrypted inserts range from roughly 11,000 rows per second for equality and order-preserving columns down to roughly 1,300 rows per second for a free-text field that generates extra bloom and ordering terms per value. These are single-machine, single-connection medians, so concurrency and your own hardware will shift them. An independent CTO playbook on field-level PII encryption published this year pegged realistic latency overhead at roughly 5 to 15 milliseconds added at the 95th percentile for indexed equality lookups, a useful cross-check against the vendor’s own numbers.

There are also functional limits that the launch materials only partially surface. Encrypted free-text matching over a paragraph-scale field is impractical, because bloom-filtered n-grams trade a small false-positive rate for index size, so the documented guidance is to reserve it for emails, names, and identifiers and to keep full-text search on non-sensitive plaintext. The ilike() and like() calls over encrypted columns are approximations built on n-gram matching, not real SQL LIKE, and the Stack API is slated to rename this to a match() method in a future release to reflect what it actually does. Separately, the Supabase wrapper in EQL 3.0.4 supports equality, range, and ordering, but encrypted free-text and JSON queries currently require an ORM adapter such as Drizzle or Prisma because PostgREST cannot express the typed operands those operations need.

Independent reviewers raised their own concerns. On the Hacker News thread covering the announcement, one commenter pressed on what guarantees the scheme actually makes, observing that the public pages said little about the threat model, what is stored, or the leakage involved, and another asked whether the CipherStash Proxy, offered as an escape hatch for direct database access, is effectively a back door. These are fair questions for an architecture that promises encryption-level security while keeping search fast. The answers live in the security architecture reference, and the advanced part of this series walks through that model in detail rather than taking the marketing copy at face value.

What this means for compliance programs

For a compliance officer or data protection officer, the value of this approach is that it changes what a breach actually exposes. Supabase already encrypts data at rest on disk and in transit over the wire, but both of those protections stop at the database boundary. Once a query reaches Postgres, every value is plaintext: visible to the database server, to any backup, to anyone with the right credentials, and to anything that logs SQL. An over-privileged role, a leaked backup, a misconfigured replica, or a SQL log shipped to a third-party observability tool all see real data.

Field-level encryption with application-held keys shifts that boundary. A stolen snapshot, an over-permissioned administrator, or a leaked query log all see ciphertext with no key, because the keys never enter the database. The Supabase announcement explicitly positions this for teams under HIPAA, GDPR, or SOC 2, and notes that keys can be split across regions to meet data-residency requirements including frameworks like FedRAMP and IL4. The practical compliance benefit is a shorter review cycle and a smaller breach surface, because the sensitive fields are cryptographically inert without the application tier.

There is a nuance worth stating plainly, because it affects how you document your controls. Searchable encryption does not eliminate leakage; it makes the leakage explicit and bounded per column. An auditor asking whether unauthorized parties can read personal data at rest can be shown that production snapshots are cryptographically inert without the application tier. An auditor asking about the search-pattern and access-pattern leakage that remains should be pointed to the capability table above and to the per-column decisions your team made. This is why the trade-off analysis part of the series spends so much time on the leakage model: the documentation you write to justify your capability choices is itself a compliance artifact.

Who this series is for and how long it takes

This series is written for two audiences that often sit on opposite sides of a table. Developers who are comfortable with SQL and the Supabase JavaScript client will get the most out of the hands-on parts, especially the tutorial, where we build a working encrypted table with equality, free-text, and range queries running over ciphertext. Security professionals and compliance owners will lean more heavily on the concepts part for the threat model and terminology, and on the trade-off analysis for the leakage model and how it maps to obligations under GDPR, HIPAA, and SOC 2.

No background in cryptography is required to start. The opening part builds from the ground up, distinguishing encryption at rest, in transit, and in use, and laying out why randomized authenticated encryption breaks equality comparisons while deterministic encryption restores them at the cost of frequency leakage. The entire series is meant to be read in sequence, but each part also stands alone well enough that you can jump to the one that matches where you are stuck right now. Each part is designed to take roughly one focused session of an hour or two, with the tutorial carrying the most hands-on setup work and the advanced part the most conceptual depth around key rotation and production hardening.

Where each part goes next

The first part establishes the concepts: what searchable field-level encryption is, what it is not, how it differs from traditional encryption, and which use cases justify the added complexity. It introduces the key terminology, including deterministic encryption, blind indexes, order-revealing encryption, and the leakage profiles that come with each, setting the vocabulary the rest of the series relies on.

The second part is the step-by-step tutorial, covering environment setup, column typing, index creation, and the encrypted Supabase client against a real project. It walks through the npx stash init flow, the EQL column types, and how equality, free-text, and range queries behave over ciphertext using the Supabase JavaScript client you already use.

The third part analyzes the security and performance trade-offs across the query capabilities, comparing schemes and their leakage profiles so you can choose per column rather than applying a single setting to an entire schema. It is the part most likely to change your mind about which fields deserve which capability.

The fourth part goes deeper into advanced techniques such as optimizing search performance, rotating keys without downtime, and integrating with existing security frameworks, alongside the common pitfalls to avoid in production, including the failure modes around identity-bound decryption and key-set isolation.

The fifth part looks ahead at future trends, the evolution of EQL, and how to stay current as these schemas mature, while the sixth wraps up with the lessons learned, a consolidated checklist, and resources for continued learning.

If you are deciding whether searchable field-level encryption on Supabase is worth your time, the answer in 2026 is largely yes, provided you go in with your eyes open about leakage and about which queries you actually need. The next part of this series, covering the core concepts and use cases, is the right first stop.

Sources and References

Sources cited while researching and writing this article:

• Searchable field-level encryption on Supabase with CipherStash
• Key management | CipherStash Docs
• GitHub – cipherstash/stack: Searchable, application-level encryption …
• Supabase Security Retro: 2025
• Searchable encryption | CipherStash Docs
• Benchmarks | CipherStash Docs
• security architecture reference

Series outline