Client-held encryption is in development and cannot be switched on yet — this page is a preview of the mechanism, not a live feature. The design: you encrypt personal data inside your own trust domain, and WattleDB only ever receives ciphertext and blind-index hashes, so our staff, our servers, our backups, and any subpoena we're served all see ciphertext where your personal-data fields used to be. Your schema, row counts, timestamps and any columns you leave unencrypted remain visible to us. You'll still be able to search it. Try it below, nothing you type leaves this browser.
A clinic saving a patient. Red fields are personal data, encrypted before they leave. Green fields are non-sensitive and stay readable so your app still works normally.
The exact payload sent to the database. Personal fields are ciphertext; searchable ones also carry a one-way blind-index hash. Non-sensitive fields are plaintext.
| id | name_enc | name_bidx | email_enc | email_bidx | dob_enc | medicare_enc | appt_type | status |
|---|
This is the raw table. Toggle "What you see" to decrypt it in your browser, the only place the key exists. A WattleDB engineer, a stolen backup, or a warrant served on us gets the left view.
A support agent looks someone up by email or name. Your app hashes the search term into a blind index; the database matches on the hash. WattleDB runs the WHERE and never sees the plaintext term or the result.
Equality match only, this is the honest limit of the free tier's blind index. "sarah" will not match "sarah.nguyen@…"; the whole value must match. Prefix/substring search is a separate, paid capability.
Encryption only means "the provider can't read it" if the provider never holds the key. So the crypto is designed to happen in your trust domain, with WattleDB only ever receiving the output:
Because the key would sit on your side, no configuration, insider, backup or legal order would let WattleDB turn that ciphertext back into a name. That is the difference between encryption at rest (we hold the key, so we can read it) and this. It is a claim about the encrypted values, not about the whole database: your schema, table and column names, row counts, timestamps and every column you leave in plaintext stay visible to us, and a subpoena served on WattleDB would still produce them.
WattleDB staff, a server compromise, a stolen backup and a subpoena served on WattleDB would see only ciphertext and hashes in the fields you encrypt. We could not produce those values, because we would not hold the key.
Table names, column names, row counts, timestamps and which rows exist stay visible to us, along with every column you leave plaintext. Encryption hides field values, not structure — so a legal order served on WattleDB would still produce a schema and those unencrypted columns.
Exact-match lookups (by email, by name) work server-side through blind indexes, so support tools and login flows keep working without decrypting the whole table.
If you lose the key, the data is gone, permanently. There is no recovery, by design. Key custody becomes your most important operational responsibility.
Blind indexes do equality only (no LIKE/range in the free tier), and low-cardinality fields (e.g. a yes/no) can leak through frequency. You choose which fields to encrypt and which stay plaintext for querying.
Australian-owned, Australian-hosted managed Postgres is available today. Opt-in client-held encryption for the fields that matter most is in development for higher plans — it is not yet available to enable.
Talk to us about encryption →