Your database provider can read your users' PII

Ask most teams "is your customer data encrypted?" and the answer is yes, encrypted at rest, encrypted in transit, box ticked. Now ask a sharper question: if your database provider wanted to read a specific customer's name, email and date of birth right now, could they? For almost every managed database, the honest answer is yes. So could anyone who compromised the provider, and so could anyone who served the provider with a valid legal demand.

Why "encrypted at rest" doesn't stop this

Encryption at rest, also called Transparent Data Encryption, encrypts the files on disk. It protects you if someone physically steals a drive or grabs a raw disk image. But the database engine has to decrypt that data to run your queries, and the provider operates the engine and holds the decryption key. From the provider's side, the data is effectively plaintext. At-rest encryption defends against a stolen disk, not against the party that runs the database. Those are completely different threats, and the marketing word "encrypted" blurs them.

The parties you're trusting without deciding to

Storing PII in a typical managed database means implicitly trusting three things: the provider's staff and internal controls, the cloud the provider itself sits on, and the legal jurisdiction that provider answers to. For a US-owned provider, that last point matters more than most Australian teams realise, the US CLOUD Act can compel a US company to produce data it controls regardless of which region it's stored in. "Sydney region" doesn't change who can be compelled.

The fix: hold the key yourself

The only way a provider genuinely can't read your data is if the provider never holds the key. That's client-side (application-level) encryption: your application encrypts sensitive fields before they're sent to the database, using a key that lives in your infrastructure. The database stores ciphertext. Staff, backups, and subpoenas served on the provider all see gibberish, because the one thing needed to reverse it, your key, was never there.

This is a real, well-understood pattern, not vapourware. The encryption uses standard authenticated encryption (AES-GCM); each sensitive field becomes a block of ciphertext that is meaningless without the key.

"But then how do I search it?"

This is the usual objection, and it has a real answer: blind indexes. Alongside each encrypted field you store a keyed one-way hash (an HMAC) of its value. To find a customer by email, your app hashes the search term the same way and the database matches on the hash, without ever seeing the plaintext. It's exact-match search over data the server can't read. We cover the mechanics in how to search encrypted data without decrypting it.

The honest limits

Client-held encryption is a real guarantee, so it comes with real trade-offs, and anyone who doesn't tell you these is selling something:

• You hold the key, and the risk. Lose the key and the data is unrecoverable. That's the point, but it makes key custody your most important job.
• Search is exact-match first. Blind indexes do equality (find the exact email), not LIKE or ranges, in the first instance.
• Not every field. You encrypt the sensitive columns and leave non-sensitive ones plaintext so your app keeps working. Choosing well matters.

Coming to WattleDB

We're building this as an opt-in feature on WattleDB: client-side encryption for your personal-data fields, keys you hold, running on Australian-owned, Australian-hosted Postgres. You can try the interactive demo to watch a record get encrypted, cross the wire as ciphertext, get searched, and decrypt only with the key, or register for early access. Sovereign hosting answers "which country can compel my provider?" Client-held encryption answers "can my provider read it at all?" Together they're a strong story.