Encryption where you hold the key.
Opt-in client-side encryption for the fields you choose, in early access on Launch and Scale. You encrypt in your own server code with keys WattleDB never receives, so for those fields we store only ciphertext and one-way hashes. Our staff, our databases and our backups hold ciphertext where your fields used to be. Your schema, row counts and unencrypted columns remain visible to us. You can still search the fields you choose by exact match.
See how it works end to end: an interactive preview of the mechanism, running entirely in your browser. It is not a connection to a WattleDB database: encrypt a record, watch only ciphertext cross the wire, then search it without ever decrypting.
Try the interactive preview →The provider that can't read your data
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 WattleDB only ever receives the output:
You use the @wattledb/encrypt library, which we provide when we grant early access, in your own server code, with keys you generate and keep. Setup is in the console, on Launch and Scale, opt-in per database. To encrypt data you already have, the library includes a migrate command.
What it protects, and what it doesn't
✅ Protects the encrypted fields from us
WattleDB cannot read the fields you encrypt, in storage, backups or logs, with the exceptions under “Data you already have” below. Our staff, our databases and our backups hold only ciphertext and hashes in those fields. We cannot produce the values, because we never receive the key.
⚠️ Doesn't 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.
✅ Still searchable
Exact-match lookups (by email, by member number, by name) on the fields you mark searchable work through blind indexes, so your app's search and login flows keep working. Rows that share a value share the same search code, so anyone holding the database can see which rows match each other.
⚠️ You hold the key, and the responsibility
If you lose the key, the data is unrecoverable, by design, and WattleDB support cannot help. Key custody becomes your most important operational task.
⚠️ Not every field, not every query
Search is exact match only (no LIKE, prefix or range), and you choose which fields to encrypt and which to leave plaintext for querying.
⚠️ Data you already have
When you encrypt existing rows, backups taken before that keep the earlier, readable form until their retention ends. The console shows the date. Clones and restores made before then keep their own copies, and database logs are kept for 365 days and can hold a value that was ever sent as SQL text or in a request URL.
⚠️ With hosted Auth
If you also use WattleDB hosted Auth, WattleDB holds the secret that signs sign-in tokens. Someone on our side who misused it could make a token for any of your users, so verify tokens yourself or add a second check before your server decrypts. Sign-in email addresses held by Auth are not encrypted.
This is an early access release. The library has not had an independent security review, and we will not describe it as reviewed until it has. Keep it away from production data you cannot afford to lose until you have tested it with us.
Want this for your app?
Tell us what you're building. WattleDB grants early access to a small group of workspaces by invitation, so there is no self-serve sign-up for it yet. Apps that hold personal data are the best fit. You need a Launch or Scale database.
Australian-owned hosting and a provider that can't read your PII
Australian-owned, Australian-hosted managed Postgres. Start free today. Client-side encryption is in early access on Launch and Scale.
Get started →