"Encryption at rest" won't stop a subpoena

"Your data is encrypted at rest" appears on nearly every cloud database's security page, and it does something useful. But it's quietly narrow. The right way to judge any encryption claim is to ask a single question: who holds the key? Whoever holds the key can read the data. Everything else follows from that.

What encryption at rest actually does

Encryption at rest, usually Transparent Data Encryption (TDE), encrypts the database's files on disk. If someone walks out with a physical drive, or pulls a raw disk image from decommissioned hardware, they get ciphertext. That's a genuine protection and you should want it. The keyword is transparent: it's invisible to the running database, which means the database decrypts everything automatically to serve queries. The engine works on plaintext in memory, all day, every day.

Where it stops

Because the provider runs that engine and holds the disk-encryption key, at-rest encryption gives you nothing against:

• The provider itself, staff with production access see live plaintext.
• An attacker inside the provider's systems, if they reach the running database or a live backup, the data is already decrypted for them.
• Legal compulsion, a valid demand served on the provider is answered with plaintext, because the provider can produce it.

A stolen bare disk is a real but relatively rare event. A provider-side compromise or a lawful access request is far more common, and at-rest encryption is silent on both.

The jurisdiction gap

That "legal compulsion" point has an Australian edge. If your provider is US-owned, the US CLOUD Act can compel it to hand over data it controls, no matter which region the bytes sit in. "Encrypted at rest in Sydney" doesn't change that, because the provider still holds the key and can be ordered to use it. Data residency is not sovereignty; a Sydney region on a foreign-owned platform is residency without sovereignty.

What actually closes the gap

To defend against the provider, an insider, or a subpoena, the provider must not hold the key. That's client-side encryption: your application encrypts sensitive fields before they reach the database, with a key held in your infrastructure. Now the provider stores only ciphertext and genuinely cannot read it, there's no key on their side to compel or steal. You keep searchability through blind indexes, and you accept the real trade: lose your key and the data is gone.

Use all three, they're not competitors

This isn't "client-side instead of at-rest." Use TLS in transit, TDE at rest, and client-side encryption on your genuinely sensitive fields. Each covers a threat the others don't. The mistake is stopping at "encrypted at rest" and believing the sensitive-data problem is solved, it protects the disk, not the data from the people running it.

How WattleDB approaches it

WattleDB already runs on Australian-owned, Australian-hosted infrastructure with no foreign entity in the ownership chain, which closes the jurisdiction gap by ownership, not just region. Client-side encryption for personal-data fields, where you hold the key, is coming as an opt-in feature; you can see it work end to end today. Sovereign ownership answers "who can be compelled?" Client-held keys answer "can they read it at all?"