We'll store it. We still won't be able to read it.
Client-side encryption is in early access on Launch and Scale, by invitation. This page is a preview of the mechanism, not a connection to a WattleDB database. You encrypt in your own server code, and WattleDB only ever receives ciphertext and blind-index hashes for the fields you encrypt, so our staff, our databases and our backups hold ciphertext where those fields used to be. Your schema, row counts, timestamps and any columns you leave unencrypted remain visible to us. You can still search the fields you choose by exact match. 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.
Search is exact match only. "sarah" will not match "sarah.nguyen@…"; the whole value must match.
@wattledb/encrypt library, which we provide when we grant early access, and WattleDB's Postgres stores what you see in panel ③ for the fields you encrypt. This is a demonstration of the mechanism, not a live connection to a WattleDB database. Want early access? Request it.
Where the key lives is the whole point
Encryption only means "the provider can't read it" if the provider never holds the key. So the crypto happens in your trust domain, with WattleDB only ever receiving the output:
Because the key sits on your side, WattleDB cannot 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. Backups made before you encrypted a field keep its earlier form until the readable-copy end date shown in the console, clones and restores made before that date keep their own copies, database logs are kept 365 days and can hold a value that was ever sent as SQL text or in a request URL, and if you also use hosted Auth, WattleDB holds the secret that signs sign-in tokens.
What this does and doesn't protect
✅ Protects the encrypted fields from us
WattleDB cannot read the fields you encrypt, in storage, backups or logs. We hold only ciphertext and hashes in those fields, and we cannot produce the values, because we never receive the key. Two exceptions: database logs are kept 365 days and can hold a value that was ever sent as SQL text or in a request URL, and clones and restores made before the readable-copy end date shown in the console keep their own copies.
⚠️ Does not hide the shape of your data
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.
✅ Still searchable
Exact-match lookups (by email, by name) work server-side through blind indexes, so your app's search and login flows keep working without decrypting the whole table.
⚠️ You hold the key, and the risk
If you lose the key, the data is gone, permanently. There is no recovery, by design. Key custody becomes your most important operational responsibility.
⚠️ Not every field, not every query
Blind indexes do equality only (no LIKE, prefix or range), 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 hosting and a provider that won't be able to read your PII
Australian-owned, Australian-hosted managed Postgres is available today. Opt-in client-side encryption for the fields that matter most is in early access on Launch and Scale, by invitation.
Talk to us about encryption →