Encrypt personal data inside your own trust domain. WattleDB only ever receives ciphertext and blind-index hashes, so our staff, our servers, our backups, and any subpoena we're served all see gibberish. You can still 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 happens in your trust domain, and we only ever receive the output:
Because the key sits on your side, there is no configuration, insider, backup, or legal order that lets WattleDB turn the ciphertext back into a name. That is the difference between encryption at rest (we hold the key, so we can read it) and this.
WattleDB staff, a server compromise, a stolen backup, and a subpoena served on WattleDB all see only ciphertext and hashes. We cannot produce your customers' PII because we do not hold the key.
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, with opt-in client-held encryption for the fields that matter most. Available on higher plans.
Talk to us about encryption →