Difference Between Field Level Encryption

On July 9, 2026, Supabase announced a field-level encryption integration with CipherStash that lets an application query its own encrypted data without decrypting a single row. The announcement upended a trade-off that security engineers had accepted for a decade: you could either protect a column from your database administrators, or you could search it, but seldom both. This first part of a six-part series on searchable field-level encryption on Supabase lays out what the technique actually is, how it differs from the encryption most teams already run, and which workloads justify the added complexity.

Key Takeaways:

• Traditional encryption at rest, in transit, and at the field level all stop at the database boundary; anything that can issue a valid query still reads plaintext after those layers finish their work.
• Randomized authenticated encryption makes search impossible because encrypting the same value twice produces different ciphertext, so a WHERE clause matches nothing.
• Searchable approaches add a deterministic, keyed index term alongside the ciphertext so Postgres can filter on encrypted values without ever seeing the plaintext or the key.
• Eight in ten sensitive-field queries in business-to-business software are equality or coarse range lookups, which makes the common case tractable today.
• Searchable encryption is not zero-leakage; it trades controlled information (frequency, ordering, access patterns) for the ability to query, and choosing per-column capabilities is the core design decision.

The problem traditional encryption cannot solve

Most databases in 2026 sit behind three encryption layers that security engineers treat as separate controls. Encryption in transit protects data while it crosses the network, which in modern transport is mostly handled by TLS. Encryption at rest protects the physical storage, whether that is the disk, the snapshot, or the backup file; in PostgreSQL this usually means transparent data encryption or plaintext columns sitting on an encrypted volume. Field-level encryption goes one step further and encrypts individual columns or fields before they are written, so the database stores ciphertext instead of the original value.

The third layer is the one that trips up compliance programs. Disk encryption and transport encryption both stop at the database boundary. Once a query reaches PostgreSQL and a role with the right privileges runs a SELECT, every value is plaintext: visible to the database server, to the backup, to the query log, and to anyone who can issue a connection. This is exactly the scenario a data protection officer worries about, because most documented breaches do not come from someone stealing a hard drive. They come from a valid connection, a leaked snapshot, a misconfigured read replica, or a SQL injection that turns into an arbitrary table dump. The Amitav Roy write-up on blind indexes as a SOC 2 control makes the point plainly: disk encryption protects you from someone walking away with the drive, but it does nothing against SQL injection, misconfigured identity and access management, or a developer who exports a production snapshot to debug an issue.

Field-level encryption is the answer to a different question, namely what an attacker sees once they have the data itself. Encrypting a column before write means the database stores only ciphertext. A stolen dump, an overprivileged role, or a leaked log all return useless encrypted bytes. The trade-off, for decades, was that encrypted columns were not searchable. The Wikipedia treatment of database encryption describes the friction: standard column-level and field-level approaches slow down indexing and searching, and the reason is structural.

Secure encryption is required to be randomized. A well-designed authenticated encryption mode like the AES in Galois counter mode used by PostgreSQL and MongoDB produces a different ciphertext every time the same plaintext is encrypted, even with the same key. That randomization is exactly what makes a keyword search impossible. A WHERE email equals clause compares the plaintext search value against stored ciphertext, and they will never match, because the stored ciphertext at write time was not produced from that exact query text. Indexes break too, because PostgreSQL cannot build a useful structure over randomized bytes. The only workaround is to pull every row, decrypt it in the application, and filter in memory, which collapses at any meaningful scale.

How searchable field-level encryption actually works

Searchable field-level encryption resolves that tension by separating the value from the information needed to query it. Instead of storing one encrypted payload and hoping a database can search it, the approach stores two things: the ciphertext that holds the real value, plus one or more derived index terms whose only job is to make specific query shapes work. This is the design the Supabase integration uses, where each encrypted value is stored as a single JSON payload containing ciphertext alongside searchable encrypted metadata (SEM) that a query can match against.

The underlying idea predates the product by more than two decades. Searchable symmetric encryption was first described by Dawn Song, David Wagner, and Adrian Perrig in a 2000 paper, and the concept has been refined ever since into a family of practical techniques. The core principle is that a server can search a collection it cannot read by comparing cryptographic tokens rather than plaintext values. In the field-level setting applied to a relational database, the database learns to answer a query by comparing derived terms, while never obtaining enough information to reconstruct the original value.

A field that must support equality search, such as an email address, gets a deterministic index term: a keyed hash, known in practice as a blind index, computed over a normalized version of the value. Because the same input always produces the same term under the same key, PostgreSQL can build a hash or B-tree index on that term and answer a WHERE email equals query by hashing the search value and comparing index entries. A field that must support ordering or range search gets a term that carries enough structure for the database to compare values relatively. A field that must support free-text matching gets a token set, such as a group of character n-grams, that the database can match probabilistically.

In every case the decryption key never reaches the database. The application encrypts before write, derives the index terms locally, and decrypts only the rows it actually returns to the caller. The database filters and sorts on encrypted terms that are useless on their own, which is the entire point. Encrypting this way is a substantive control under frameworks like HIPAA, GDPR, and SOC 2, because it changes what a breach actually exposes: a stolen production snapshot becomes cryptographically inert without the application tier.

Traditional field-level encryption versus searchable encryption

The clearest way to see the difference is to line the two approaches up against the same query workload. The table below compares how each approach behaves across the operations a real product cares about.

The benchmark reality is that searchable encryption costs more than plaintext but far less than the decrypt-everything workaround. A Newsoftwares reference benchmark on a local PostgreSQL instance with one million user records found that indexing a plaintext-encrypted column with a B-tree took 48 seconds for the insert workload and 6 milliseconds for a point lookup, with a 150 megabyte index. Adding a deterministic ciphertext index pushed insert time to 62 seconds and lookup to 7 milliseconds at the same index size. The realistic searchable design, random ciphertext plus a separate blind-index column, cost 78 seconds to load and 8 milliseconds to look up, and grew the index to 210 megabytes. Write time suffers more than read time, because each write must encrypt the value and compute every index term, while a read simply hashes the search input and walks an index.

The dhdtech CTO playbook for 2026 puts the operational numbers in shopping terms. Equality search with a blind index adds roughly 1.1 to 1.3 times storage per field and 5 to 15 milliseconds of latency at the 95th percentile over a typical indexed lookup, driven mostly by application-layer tokenization and post-filtering. Bucketized ranges for dates or amounts add a 1.2 to 1.5 times false-positive amplification that the application must filter out, with 10 to 30 milliseconds of added latency at the 95th percentile. Full-text search over a dedicated encrypted service is the most expensive, with indexes running 2 to 5 times the raw text size and reads adding 25 to 60 milliseconds at the 95th percentile. These are ballpark figures that shift with network topology and object relational mapping behavior; they are useful for budgeting, not for fine commitments.

Key terminology you will need

The field uses a specific vocabulary, and the rest of this series depends on it. Understanding these terms before touching a schema will save you from the most common design mistakes.

Randomized authenticated encryption. The default, strongest mode. Produces a different ciphertext each time, even for the same plaintext and key. Excellent confidentiality, no searchability. Used for fields that never need to be queried.

Deterministic encryption. Produces the same ciphertext for the same plaintext under the same key. Restores equality search because identical values map to identical output, but leaks frequency: the database can see which values are equal and how often each appears. Best for high-cardinality, uniformly distributed values like random record IDs.

Blind index. A separate keyed hash of the normalized plaintext, stored alongside the ciphertext. This is the workhorse of equality and prefix search, because it lets PostgreSQL index and match on a deterministic value without holding the actual value. A blind index is only as strong as its salt and key management; using a plain SHA-256 instead of a keyed message authentication code leaves it vulnerable to rainbow-table lookup.

Order-revealing and bucketized range terms. Two ways to make range queries work. True order-revealing encryption lets the database compare values relatively but leaks the complete ordering. Bucketization maps a value to a coarse bucket, such as a month or a ten-dollar range, trading precision for less leakage and accepting false positives that the application filters.

Leakage. The controlled information a searchable scheme reveals to the database or an observer. Every capability reveals something: equality exposes frequency, ordering exposes relative position, and free-text exposes token structure. There is no zero-leakage searchable design, a point the honest-state overview of searchable encryption stresses. Frequency-analysis attacks against deterministic deployments are well documented, so a low-cardinality, easily joinable field like a medical diagnosis is risky for deterministic search while a random identifier is not.

Canonicalization. Normalizing input before deriving an index term, so that “[email protected]” and “[email protected]” resolve to the same token. Skipping this step multiplies ciphertexts and index terms for the same logical value and torpedoes match rates.

Use cases, plus the honest trade-offs

The practical trigger for adopting searchable field-level encryption is a three-part condition: the application handles genuinely sensitive data, that data must remain queryable, and the team wants to keep keys away from the cloud operator and database administrators. The clearest use cases are identity data such as email, phone, and national identifier fields in customer records; financial data such as card and account numbers in payment systems; and health or legal notes under HIPAA-grade obligations. In each case the application needs equality lookups, and in some it needs coarse date or amount ranges.

The dhdtech playbook reports that about 80 percent of sensitive-field queries in business-to-business software are equality or coarse range searches. That matters because it means the common case is tractable with deterministic encryption and blind indexes today, without resorting to fully homomorphic encryption, which remains impractically slow for general-purpose workloads, or to trusted execution environments, which shift trust onto hardware vendors and are operationally heavy. Searchable field-level encryption is the middle path: strong confidentiality on the stored values, real searchability for the queries that dominate, and a bounded, explicit leakage model.

The trade-offs are real and should shape the decision. The database and cloud provider cannot read the sensitive values, but they can observe access patterns and result sizes, and over time they can infer which records share values. A fully compromised application tier holds the keys and can decrypt everything, so this control protects data against database and cloud insiders, not against an attacker who owns your application process. Key rotation requires re-encrypting rows, which on large datasets is a background migration, not a switch you flip. And free-text search over sensitive text is an index-heavy approximation, not true SQL LIKE matching, which is why the guidance in this series is to reserve encrypted free-text for emails, names, and short identifiers.

Given those constraints, the honest stance is that this control is additive, not a replacement for layered security. It reduces breach impact, shortens compliance review cycles, and makes production snapshots cryptographically inert, but it does not remove the need for good key management, least-privilege access, row-level security at the database layer, and a properly trained operations team. Its strongest role is as the data-layer control that keeps sensitive values out of reach of the database itself, which is something no amount of disk encryption or access policy can do.

What comes next in this series

This part has built the conceptual foundation: what the technique is, how it differs from traditional encryption, and which use cases justify it. The vocabulary is now in place for the deeper work ahead. The next part in this series is a step-by-step guide to implementing searchable encryption in Supabase, covering environment setup, choosing the right encryption schemes per field, and wiring search capabilities into a real project. That is where the concepts here turn into a working encrypted table running equality and range queries over ciphertext. You can also return to the series overview to see how all six parts fit together.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Searchable Field Encryption on Supabase

Sources and References

Sources cited while researching and writing this article:

• Searchable field-level encryption on Supabase with CipherStash
• Field-Level Encryption With Searchable Blind Indexes: A Practical SOC2 Control Worth Understanding
• Database encryption – Wikipedia
• Searchable symmetric encryption – Wikipedia
• Field Level Encryption In SQL/NoSQL : Search/Index Trade-offs – Newsoftwares.net Blog
• Searchable Encryption That Ships in 2026
• Searchable Encryption , the Honest State of the Field – Amazing Resources