Every vendor benchmark is written by the winner, after the fact, against a comparator configured by the winner. Readers know this, discount accordingly, and are usually right to. We intend to publish a comparison that does not deserve the discount, so we are doing the one thing that removes it: stating the protocol first.
The comparison is between 8DB's record-level algorithm migration on a running store and Oracle Database's online tablespace encryption rekey and conversion. We chose Oracle because it is the strongest incumbent answer to the question NIST CSWP 39 section 5.1 poses for data at rest: change the algorithm on already-stored data without stopping the system. Online rekey does that today, for the AES-to-AES case, and any honest account of the market says so. If our approach is better, it has to be better than that, on the same records, under conditions the reader can reproduce.
This article is for database engineers, security architects and the programme leads who will have to choose a migration mechanism and defend the choice. It is the protocol. The results will appear in a follow-up article that links back here,1 and if the results embarrass us, they will still appear.
The question being asked
For a defined set of already-stored records, change the cryptographic protection while reads and writes continue, then prove completion. The measurements that matter are not throughput alone. They are the ones an operator lives with.
| Metric | Why it matters |
|---|---|
| Wall-clock time to complete the migration at fixed record count | The window the operator has to plan for |
| Longest stall observed by concurrent readers and writers | Whether "online" means online for the application |
| Read and write throughput during migration as a fraction of baseline | The cost the business pays while it runs |
| Storage written during migration relative to dataset size | Whether the operation rewrites everything or only what changed |
| Completion evidence | Whether the system can state, per record, that the change happened, and list exceptions |
| Behaviour on interruption and restart | Whether an interrupted migration leaves a coherent store |
| Restored-backup behaviour | Whether an old copy restored afterwards obeys current keys and policy |
Fixtures
- Records. A fixed synthetic dataset of 115-byte records, the same fixture used in our published measurements, at counts of 100,000 and 1,000,000, generated from a published seed so anyone can regenerate byte-identical data.
- Workload during migration. A steady mixed read and write load at a published rate, generated by a published harness, running throughout.
- Starting state. Both systems begin with all records protected under a classical configuration. Oracle: AES-256 tablespace encryption with the current master key. 8DB: records sealed under keys established by a classical key-derivation function.
- Target state. Oracle: the documented online rekey to a new master key and, separately, the documented online conversion to a different algorithm where supported. 8DB: registration of a new algorithm version, quarantine of the old, and the re-encryption sweep with reads continuing.
We will publish the exact Oracle commands and parameters, the 8DB configuration, the harness source and the seeds. Where Oracle offers a tuning that improves its result, we will use it and say so.
Hardware and disclosure
Both systems run on the same host class, disclosed by model, core count, memory and storage, with the operating system and versions recorded. Each measurement carries its host and date. We will not compare a number from one host against a number from another, and we will not publish a ratio without the two absolute values beside it. Runs are repeated; we report medians and the spread. Nothing is quoted as a single best run.
What each system is being asked to prove
This is where the comparison stops being only about speed. Oracle's online rekey changes the key or algorithm at the tablespace level and rewrites the datafile. It does not carry an algorithm version on each record, does not serve mixed-version reads by design, and does not have a quarantine state.2 8DB carries a version on every ciphertext, serves old and new versions during the sweep, and treats the retired algorithm as a state that refuses writes. The protocol asks both systems the same completion question afterwards: which records, if any, still depend on the old protection, and how do you know.
We will name which of the five transition operations each run performs, because "algorithm swap" hides five different contracts: key rotation within a cipher, key-protection transition, data-cipher replacement, signature transition and authorisation-policy transition. A run that rotates a key is not a run that replaces a cipher, and the article will not blur them.
Acceptance criteria, stated now
For us to claim an advantage on any row of the table above, 8DB must beat the tuned Oracle configuration on that row on both record counts, across repeated runs, with the spread published. For rows where Oracle wins or the result is within the spread, we will say Oracle wins or that the result is a tie. For the completion-evidence and restored-backup rows, the criterion is qualitative and will be described with the exact behaviour observed on both systems.
Why publish this before the result
Three reasons. Readers in this field are right to discount post-hoc benchmarks, and the only cure is a protocol they can hold us to. Our own doctrine says a number without its scope and harness is not a number, and a protocol is how scope is fixed before the temptation to move it arrives. And the buyers we care about, in agencies and regulated institutions, are being told by the guidance itself to demand reproducibility. We would rather be the vendor who wrote the acceptance criteria before the test.
What to bring us
- Your Oracle configuration. If you run online rekey in production, tell us how you tune it. We would rather compare against how it is actually operated than against a default.
- Your workload shape. Record size, read and write mix, and the stall you can tolerate. We will add a fixture that looks like you.
- Your presence. If you want to observe or reproduce the runs, the harness and seeds will be available before the results are.
Write to hello@8braid.com with the subject "Migration benchmark protocol: participate". You will hear back from an engineer.
Sources and further reading
- Oracle Database 26ai: online tablespace encryption and Data Guard
- Oracle Database: Transparent Data Encryption changes in this release
- NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility, section 5.1
- 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
- 8DB: The 2035 Migration Is Already Scheduled. Is Yours?
Footnotes
-
No result is claimed in this article. No run has been published, no number is quoted, and nothing here should be read as implying which system wins on any row. ↩
-
Those are not criticisms of Oracle's mechanism; they are the shape of it, and the protocol measures what that shape costs and what it gives. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work