Whilst Quantum Computing is in the news, database encryption is the control your board, your auditor and your CISO all ask about. It is also the one most commonly misunderstood. In 2026 it is sitting between two pincers: quantum computing on the horizon, and the everyday reality of credential and key compromise that has dominated breach reports for the last decade.
The Australian Signals Directorate has now put dates on the wall — refined post-quantum transition plans by end of 2026, implementation underway by end of 2028, transition complete by end of 2030. Boards are starting to ask infrastructure managers and architects pointed questions about how their data is actually protected.
This article looks at what is actually on offer across the three mainstream relational databases — Oracle, SQL Server and PostgreSQL — both on-premise and across the major hyperscalers. It then looks at where quantum computing genuinely changes the threat model (and where it does not), examines a unified third-party encryption option from Randtronics, and finishes with the reasons encryption alone is never enough.
encryption is a baseline control, not a strategy, and the threats most likely to break your database in 2026 have nothing to do with qubits
Oracle's flagship encryption capability is Transparent Data Encryption (TDE), which encrypts data at rest at either the column or tablespace level. The catch is that TDE is part of the Advanced Security Option, which is licensed separately and only available on Oracle Enterprise Edition. That is an extra sting of 31.5% on top of an already expensive offering.
Oracle Standard Edition gets nothing native at the database layer for data at rest. Only Native Network Encryption and TLS for data in transit. This is an awkward truth that affects a lot of Australian organisations running smaller Oracle estates on SE2 to keep licensing costs sane.
Key management uses Oracle Wallet, which is included, or Oracle Key Vault, which is licensed separately. Oracle 26ai now ships quantum-resistant algorithms and AES-XTS as the default tablespace cipher, and FIPS 140-3 support for Oracle Database 19c has been stated to land during 2026.
SQL Server has two complementary encryption capabilities that are often confused. TDE encrypts the entire database at rest at the storage engine layer. Always Encrypted operates client-side, encrypting specific columns before the data ever reaches the database engine, with the keys held by the application. That second model is genuinely strong against a compromised DBA, because the database literally never sees the plaintext or the key.
The often-missed detail: TDE has been available in SQL Server Standard Edition since SQL Server 2019. It was Enterprise-only before that. Many people still believe SQL Server TDE requires Enterprise licensing, and it does not. Always Encrypted has been in Standard since SQL Server 2016 SP1.
Cell-level encryption via EncryptByKey is also available for granular use cases. EKM (Extensible Key Management) is a SQL Server feature that lets the database engine offload key storage and cryptographic operations to an external module — most commonly a Hardware Security Module (HSM) — rather than keeping keys in the SQL Server keystore itself.
Community PostgreSQL has no native TDE. Worth stating plainly because the marketing around managed PostgreSQL services often blurs this.
What you actually get with community PostgreSQL is filesystem encryption (LUKS, dm-crypt, BitLocker), the pgcrypto extension for column-level encryption inside the database (with pgsodium as a more modern alternative), TLS for connections, and SCRAM password hashing. That is a complete defence-in-depth stack if assembled correctly, but it is not the same as Oracle and Microsoft's offers. The Randtronics solution could also apply here, that is discussed further below.
Many organisations assume that moving to AWS, Azure, Google Cloud, OCI, IBM Cloud or Alibaba Cloud automatically delivers a higher class of encryption than they could manage themselves. The hyperscalers have eye-watering margins, deep security investment, and impressive compliance certifications. Surely the defaults are good enough?
Not really.
The encryption the hyperscalers provide by default is overwhelmingly storage-layer, not engine-layer. That is enough to satisfy auditors and tick PCI DSS, HIPAA and ISO 27001 boxes — those frameworks were largely designed around physical-media-theft threat models from the 2000s. It is not enough to address the threats that have dominated breach reports for the last decade: compromised credentials, abused service accounts, and stolen keys.
If a hyperscaler encrypts your storage volume, that protects you if a disk gets stolen out of a data centre. Has that ever happened ? It does nothing if an attacker has a valid database connection. And the defaults vary wildly between providers — sometimes between services within the same provider — in ways that surprise architects who assume the cloud is uniform.
A few examples worth calling out specifically.
License-included RDS Oracle, including SE2, can be encrypted at rest via AWS KMS at the EBS volume layer. This is not Oracle TDE. It is volume encryption similar to what you would get with LUKS on a Linux VM.
The critical detail: this is only on if you ticked the encryption box at instance creation. If the default is to not enable it, you cannot change it after the instance exists. Plenty of License-included RDS Oracle databases out there in production are unencrypted at rest because nobody explicitly enabled it during provisioning. This is a real audit finding worth checking.
Oracle TDE on RDS still requires BYOL with Advanced Security Option licensed. You can run KMS volume encryption and Oracle TDE together if your compliance posture demands belt-and-braces.
Short answer: yes, and that matters.
All data is always encrypted at rest. AES-256 via the FIPS 140-2 validated Azure Storage cryptographic module. You cannot turn it off. Two modes — service-managed keys (default, automatic) or customer-managed keys where your KEK (Key Encryption Key) in Azure Key Vault wraps the storage DEK (Data Encryption Key). The mode is locked at server creation.
It is the same threat model as on-premise LUKS or dm-crypt. It protects against physical media theft or offline backup access. It does nothing against a valid database connection, a compromised account, or a pg_dump walking out the door.
Microsoft's documentation compares it to Oracle and SQL Server TDE. That comparison is generous. Real TDE encrypts data blocks as the engine reads and writes them, with key separation owned by the database. Azure PostgreSQL Flexible Server has neither.
The customer-managed key feature does give you a kill switch — revoke the key in Key Vault and the database becomes inaccessible shortly thereafter. That is a meaningful control even if the underlying encryption is storage-layer.
Same boat as Azure. KMS volume-level encryption only, no native TDE inside the engine. pgcrypto is your option if you need column-level inside the database. The KMS encryption is optional at instance creation and cannot be changed afterwards.
Google's defaults are stronger here. All Cloud SQL data is always encrypted at rest with AES-256, no exceptions, no toggle. You get Google-managed keys by default or can switch to customer-managed keys via Cloud KMS or Cloud HSM. For Cloud SQL for SQL Server, you get a two-layer model — Google's storage encryption plus SQL Server's own engine-level TDE. For PostgreSQL, it remains storage-layer only and you fall back to pgcrypto for column-level.
OCI has the strongest Oracle defaults. Autonomous Database, Base Database Service and Exadata Cloud Service all have Oracle TDE on by default at AES-128 (worth bumping to AES-256 if your data has a long sensitivity horizon). Keys live in OCI Vault or Oracle Key Vault.
Worth knowing: Oracle Database@AWS, Oracle Database@Azure and Oracle Database@Google Cloud are all now available — these are Oracle Exadata hardware co-located inside the hyperscaler data centres, jointly operated, with Oracle-managed TDE encryption. If you are running Oracle workloads on AWS, Azure or GCP and you want proper Oracle TDE rather than volume-level KMS, this is a strong path to consider.
IBM Cloud's standard Databases for PostgreSQL is AES-256 at rest by default with BYOK via Key Protect — broadly similar to its peers.
IBM Hyper Protect DBaaS for PostgreSQL runs on IBM Z / LinuxONE confidential computing hardware and offers Keep Your Own Key (KYOK) via Hyper Protect Crypto Services. The HSMs are FIPS 140-2 Level 4 certified — the highest certification available — and the architecture provides technical assurance that IBM administrators cannot access your keys. This is genuinely the strongest separation-of-duties model on offer in the public cloud market. It is also a useful counterpoint to "all hyperscalers are the same" — they are not.
ApsaraDB RDS for PostgreSQL and ApsaraDB RDS for SQL Server both offer engine-level TDE as an optional feature, with keys managed via Alibaba KMS and BYOK supported. Notably, Alibaba developed its own TDE for PostgreSQL, which is rare in the market. The default state for both is unencrypted at rest, similar to AWS RDS.
Hyperscaler encryption is a thin layer that satisfies compliance frameworks built around an older threat model. Defaults vary, the difference between "encrypted" and "engine-level encrypted" matters, and the responsibility for actual data protection — credentials, access patterns, audit, key custody, field-level protection — sits with you, not with the cloud provider's marketing page.
If you depend on a hyperscaler default and have not personally verified what it does and does not protect against, you are accepting a 2008-era threat model in 2026.
---
Quantum computing is real, the looming threat is real, and the headlines are mostly overstated when applied to databases. Some clarity is overdue.
The quantum threat to cryptography splits cleanly along symmetric versus asymmetric lines.
Asymmetric algorithms — RSA, ECC, Diffie-Hellman — are broken by Shor's algorithm running on a sufficiently powerful quantum computer. This is the genuine problem. It affects TLS handshakes, code signing, certificate authorities, key wrapping when an HSM uses RSA, and the public-key authentication built into modern PKI.
Symmetric algorithms — AES, and the hash functions like SHA-256 — are only affected by Grover's algorithm, which is a quadratic speedup, not a break. Grover's is also notoriously difficult to parallelise, which substantially erodes the theoretical speedup in practice.
Effectively yes, according to NIST.
Grover's algorithm in theory reduces the effective key length of AES-128 from 2128 to roughly 264 operations. That sounds alarming until you read what NIST itself says: Grover's is so hard to parallelise that the real-world advantage is far less than the theoretical maximum. NIST uses AES-128 as the benchmark for its post-quantum Category 1 security level. If AES-128 were not safe, the entire NIST post-quantum framework would be in doubt.
NIST's published position, paraphrased: Grover's algorithm will likely provide little or no practical advantage in attacking AES, and AES-128 will remain secure for decades. There are links to NIST at the end of this article.
Yes, with comfortable margin.
Under Grover's algorithm, AES-256 retains an effective post-quantum security strength of about 2128, which is the classical security equivalent of AES-128. That is considered safe for the foreseeable future. For data with a long sensitivity horizon — 10 years and beyond — AES-256 is the conservative engineering choice.
Your TDE or at-rest AES encryption is not the quantum problem. If your tablespaces or columns are encrypted with AES-128 or AES-256, the symmetric protection of that data at rest is already quantum-resistant by NIST's own framework.
The quantum problem sits in everything around the AES core: TLS connections to the database, RSA-wrapped backup keys, certificate-based authentication, the asymmetric key exchange between your HSM and your database, code signing for your software supply chain. These are the harvest-now-decrypt-later targets.
Headlines that say "quantum will break your encrypted database" conflate symmetric and asymmetric encryption. They are wrong, however, if your now-secure TLS traffic is captured for later harvesting via quantum computing, the traffic will be decrypted and data will be obtainable. If RSA were to be decrypted, that could lead to decrypting the Key Encryption Key which could then result in the Data Encryption Key being decrypted and this could lead to the encrypted database being decrypted. So it is not the database encryption being broken by quantum, it is the weakest link being targeted that is the true threat, TLS and RSA.
Disclosure: Pebble IT is a partner of Randtronics and has implemented their encryption capabilities at customer sites, including for Oracle Standard Edition where no native option exists. That implementation experience informs this section.
Randtronics' Data Privacy Manager (DPM) suite addresses several gaps that exist in the native database vendor offerings, particularly for organisations running multiple database technologies.
DPM easyCipher is an agent-based transparent file and folder encryption capability that sits outside the database. It works across Oracle (including SE2), SQL Server (all editions), PostgreSQL (community and forks), MySQL, MariaDB, DB2 and SAP HANA — one console, one policy. Functionally it delivers a TDE-like outcome, though architecturally it operates at the OS file layer rather than at the database block layer.
DPM easyData is the column-level field-protection capability — tokenisation, masking, format-preserving encryption, anonymisation. There is a no-code agent for Oracle and SQL Server, and a clientless connector for PostgreSQL, MySQL and MariaDB.
DPM easyKey provides centralised key management with multi-vendor HSM support certified to FIPS 140-3 Level 3/4 and Common Criteria EAL 4+/5+, with dual-control authorisation.
Three failure modes that encryption alone does not address.
Do we have clients that do all of the above ? No. The above shopping list is not easy to achieve, however that should not stop long-term planning to address these.
If reading this has surfaced uncertainty about your own environment — what is actually encrypted, where the keys live, whether your hyperscaler defaults are doing what you think they are doing — that is a productive uncertainty to act on.
Pebble IT works across Oracle, SQL Server and PostgreSQL on-premise and across all major hyperscaler platforms. We have implemented Randtronics at customer sites where native options do not fit the requirement, and we are equally happy to advise where native options are perfectly adequate. We will give you an honest assessment of where your gaps are.
Encryption is a baseline, not a strategy. AES at rest is not the quantum problem — key exchange, certificate infrastructure and asymmetric key wrapping are. Hyperscaler defaults satisfy auditors more reliably than they satisfy threat models, and architects who depend on them without checking are accepting a much older risk profile than they realise. The realistic 2026 threat to your database is still credentials and keys, not qubits.
The Australian Signals Directorate has put the dates on the wall — 2026 for a refined plan, 2028 for implementation to be underway, 2030 for transition complete. The time to start is now.
Both are commonly described as having no encryption, which is not quite right but is close.
Oracle Standard Edition has no native encryption at rest. TDE requires Enterprise Edition plus the separately-licensed Advanced Security Option. On-premise, your choices are filesystem encryption (LUKS, BitLocker), application-layer encryption, or a third-party agent such as Randtronics DPM easyCipher. On AWS RDS, License Included Oracle SE2 can be encrypted at the storage layer via AWS KMS, but only if you enabled it at instance creation. Oracle Native Network Encryption and TLS are included for in-transit protection on all editions.
Community PostgreSQL has no native TDE. Options are filesystem encryption, the pgcrypto extension for column-level encryption inside the database (and pgsodium as a modern alternative, see the next FAQ), TLS for transit, and SCRAM password hashing.
Both are PostgreSQL extensions that provide column-level encryption inside the database. They are not alternatives to TDE — they encrypt specific fields you nominate, not the whole database — but they are often the most practical path for community PostgreSQL when sensitive columns need protecting and a commercial fork is not on the table.
pgcrypto is the long-standing option, included with PostgreSQL since version 8.3 (2008). It works, it is widely deployed, and it ticks the compliance box for column-level encryption. However the PostgreSQL community itself has raised concerns about its code quality — it contains outdated algorithm implementations and predates modern authenticated-encryption constructions. That may change if the extension is maintained and updated.
pgsodium is the modern alternative. It wraps libsodium, a well-regarded cryptographic library based on Daniel Bernstein's NaCl, and adds several capabilities pgcrypto does not offer:
The caveat: pgsodium has higher operational complexity and a real risk of misconfiguration. Supabase, previously one of the largest commercial deployments of pgsodium, has moved it to pending deprecation on their managed platform for those reasons. The extension itself remains actively developed and is not deprecated — but the largest managed adopter has stepped back from recommending it for general use.
Practical recommendation. For new deployments where you need column-level encryption inside community PostgreSQL, pgsodium is the technically superior choice if you have the operational maturity to deploy and manage it properly. If you do not, pgcrypto remains usable for simple cases but should not be your long-term answer. The better path for most organisations with serious data sensitivity could be Randtronics that delivers field-level protection without requiring you to operate the cryptographic plumbing yourself.
No. Encryption protects data when someone steals the disk, the backup tape, or the storage snapshot. It does very little when an attacker has valid credentials — which is how almost every breach actually happens. Encryption needs to be paired with strong key management, privileged access management, database activity monitoring, and field-level protection (tokenisation or masking) for the truly sensitive data. Encryption is the foundation, not the building.
Effectively yes, according to NIST. Grover's algorithm theoretically halves the effective key length under quantum attack, but Grover's is extremely hard to parallelise and the practical speedup is far less than the theoretical maximum. NIST uses AES-128 as its baseline for post-quantum Category 1 security and states that AES-128 will remain secure for decades. AES-128 is not the urgent quantum problem.
Yes, with comfortable margin. Even under Grover's algorithm, AES-256 retains an effective 128-bit security strength against a quantum attacker, which is considered safe for the foreseeable future. AES-256 is the conservative choice for data with a long sensitivity horizon — 10 years or more.
Not for the encryption of your data at rest. If your existing Oracle TDE uses AES-128 or AES-256, the symmetric encryption protecting your data is already quantum-resistant within NIST's framework — moving to 26ai does not change that.
What Oracle 26ai adds is post-quantum cryptography for the asymmetric operations — key exchange, key wrapping, signatures — which is where the real quantum threat actually sits. Oracle has indicated that FIPS 140-3 support for Oracle Database 19c is landing during 2026, so 19c customers will have a path that does not require a full upgrade. Whether to move depends on your data sensitivity horizon, whether your TLS and backup-key-wrapping use RSA-based mechanisms, and your wider PQC strategy.
The Australian Signals Directorate, through the Australian Cyber Security Centre, has published *Planning for Post-Quantum Cryptography* with three concrete deadlines for Australian organisations:
The ASD's Information Security Manual lists the approved post-quantum algorithms, built on the NIST standards ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). The 2030 deadline already incorporates a buffer for technological uncertainty — organisations are expected to add their own buffers for legacy systems, vendor dependencies and supply chain complexity.
