The word “blockchain” has been so thoroughly overused in enterprise marketing that most experienced DBAs instinctively tune out when they see it. I get it. But Oracle’s Blockchain Tables implementation is worth a second look — not because of the branding, but because of what’s actually happening technically, and because the 23c additions genuinely change what you can do with it.
Let me explain what this feature actually is, what’s new in 23c, and where I think it’s genuinely useful versus where organizations tend to overcomplicate things.
What Oracle Blockchain Tables Actually Are (Without the Hype)
Strip away the marketing and Oracle Blockchain Tables are a specialized table type with three defining characteristics: you can only insert rows, you can’t update or delete them within their retention window, and each committed row carries a cryptographic hash that’s linked to the previous row in the chain.
That last part is the piece that matters. If someone tampers with a stored row — modifies it through some privileged path, alters it at the storage level — the hash chain breaks. Verification fails. The tampering is detectable. This isn’t theoretical protection; it’s a mathematical guarantee that you can verify at any time by checking the chain.
What this makes Oracle Blockchain Tables good for: audit logs you need to prove weren’t altered, financial records with regulatory retention requirements, compliance documentation where chain of custody matters, any situation where “this data was recorded and has not been changed since” needs to be provable rather than just assumed.
What they’re not: a replacement for distributed blockchain systems in scenarios that actually require decentralization and multi-party consensus. Oracle’s implementation lives inside your Oracle database, which means Oracle (and privileged DBAs with enough access) are still part of your trust model. For most enterprise use cases, that’s fine. For use cases where the whole point is removing any single trusted party, it’s not the right tool.
Being clear about that distinction upfront saves a lot of architectural confusion later.
Version 1 vs Version 2: Why the Distinction Matters
Oracle introduced Blockchain Tables in 21c. That was Version 1 — useful, but limited. System-defined chaining, basic retention controls, insert-only protection. It established the foundation.
23c brings Version 2, and the gap between them is significant. Version 2 tables require more hidden metadata columns — 40 versus 20 in Version 1 — but that overhead buys you a substantially different feature set: row versioning, user-defined chains, delegate signers, countersignatures, column add/drop support, and proper replication support through GoldenGate and Active Data Guard.
If you deployed Blockchain Tables in 21c and have been wondering whether 23c changes anything meaningful, the answer is yes. These aren’t incremental refinements; they’re capabilities that weren’t there before.
Row Versions: Finally, Business-Context History
In Version 1, historical tracking meant querying your append-only records chronologically and inferring relationships yourself. For simple use cases, that worked. For anything involving a long-lived business entity — a customer account, a contract, a regulated record with many state changes over time — it got messy.
Row Versions in 23c lets you define up to three user-defined columns as version identifiers, creating a structured way to link rows that belong to the same logical entity. The database automatically maintains a view with a _LAST$ suffix that gives you the most recent version of each entity without you having to write that logic yourself.
The practical example that makes this concrete: a bank customer’s account has an opening transaction, deposits, withdrawals, fee charges, and transfers spread across potentially thousands of rows over years. With Row Versions, all of those rows are explicitly version-linked through the account identifier. An auditor asking “show me the complete history of this account, in order, with proof it hasn’t been altered” gets a clean answer instead of a complicated query.
The column type support is reasonable — NUMBER, CHAR, VARCHAR, RAW — which covers the natural key types you’d use for business entity identification. This isn’t a feature you’ll need on every blockchain table, but for entity-centric audit trails it’s the missing piece from Version 1.
User Chains: Custom Chaining Logic for Real Workflows
Version 1 chaining was system-managed. Every row was chained to the previous row, full stop. That’s cryptographically sound but organizationally blunt — it chains everything together regardless of whether rows are logically related.
User Chains let you define chaining based on your own business columns. Instead of one global chain across the entire table, you can have separate cryptographic chains per bank, per account, per transaction type — whatever grouping makes sense for your data model and your audit requirements.
Why does this matter? Consider a multi-tenant financial system where you need to prove to Bank A that their records haven’t been tampered with, without involving Bank B’s chain at all. System-defined chaining makes that proof harder to isolate. User Chains gives you chain boundaries that correspond to actual business boundaries.
This also improves forensic precision. When you’re investigating a specific account or entity, you’re verifying a chain of relevant records rather than navigating a chain that includes everything else in the table. Faster verification, cleaner evidence, more meaningful audit output.
Delegate Signers: Approval Workflows Built Into the Chain
This one addresses a real operational gap that anyone who’s thought carefully about blockchain table signing has run into.
The basic signing model is: the user who inserts a row can sign it with their private key, cryptographically binding their identity to the record. That’s clean and simple, but it doesn’t reflect how approvals actually work in most organizations. Transactions get approved by managers. Compliance entries get validated by compliance officers. Critical records get authorized by someone other than the person who created them.
Delegate Signers formalizes this. A user with the SIGN privilege can be authorized to digitally sign rows on behalf of the record creator, using certificate-based identity verification. The signer’s identity gets recorded in the hidden metadata columns alongside the original insertion.
The governance implications are real. You can now construct blockchain records that capture not just “this data was inserted” but “this data was inserted and subsequently approved by these identities.” For regulated industries where multi-party sign-off on records is a compliance requirement, this turns blockchain tables from a storage mechanism into a proper approval workflow with cryptographic evidence.
The implementation requires actual digital certificate infrastructure — this isn’t a feature you configure in an afternoon without that foundation already in place. But if you have PKI infrastructure and approval workflows that need verifiable evidence, it’s worth looking at seriously.
Countersignatures: Third-Party Verification
Countersignatures take the trust model one step further. Where a regular signature says “this was inserted by this identity,” and a delegate signature adds “and approved by this identity,” a countersignature says “and an external party confirms this record exists in the state I’m attesting to.”
In practice, this means an auditor, a regulator, or a trusted third party can sign a blockchain table row to confirm they’ve verified it. That signature gets recorded — and can be stored externally for independent verification — creating a chain of evidence that extends outside the database itself.
The use cases here are specific but important: legal proceedings where you need to demonstrate records were intact at a point in time, regulatory submissions where third-party attestation is required, financial audits where external auditors need to leave a verifiable footprint. Countersignatures don’t make sense for every blockchain table deployment, but when you need that level of non-repudiation, having it built into the database is significantly cleaner than building it yourself.
Retention Controls and the Limitations You Should Know About
Oracle gives you two levels of retention control. At the table level, NO DROP UNTIL X DAYS IDLE prevents the table itself from being dropped while data remains within the retention window. At the row level, NO DELETE UNTIL X DAYS AFTER INSERT protects individual rows for a defined period. You can also set permanent retention for data that should never be eligible for deletion.
These controls are enforced at the database level, which is where you want enforcement to be — not at the application level where a code change could inadvertently bypass them.
On limitations: this is where the blog posts tend to get thin, but I think it’s worth being direct. Blockchain Tables don’t support XMLType, LONG columns, TIMESTAMP WITH TIME ZONE, TRUNCATE, UPDATE, MERGE, DBMS_REDEFINITION, sharded tables, or certain Oracle security policies. If your data model requires any of those, you either need to redesign around them or reconsider whether Blockchain Tables are the right storage mechanism for that particular data.
Also worth noting: the metadata overhead is real. Version 2 requires 40 hidden columns per table. For tables that are insert-heavy and high-volume, storage planning needs to account for this. It’s not prohibitive, but it’s not free either.
Where This Actually Belongs in Your Architecture
Oracle Blockchain Tables in 23c are genuinely useful for a specific class of problem: enterprise audit and compliance data that needs to be stored inside Oracle (not on an external blockchain), needs provable tamper-resistance, and benefits from structured versioning, custom chaining, or multi-party signing.
The pattern I’d watch out for: using them for everything that touches compliance because “blockchain” sounds appropriately serious. The feature adds overhead — metadata columns, verification complexity, signing infrastructure if you go that route — and that overhead is justified when the tamper-resistance and audit properties are actually required, not when a regular table with proper access controls would do the job.
For financial transaction ledgers, regulatory audit trails, compliance documentation, and any scenario where you need to prove data hasn’t changed since it was written — that’s where Version 2 delivers real value. The Row Versions and User Chains additions in particular close the gaps that made Version 1 feel limited for complex, entity-centric use cases.
If you deployed Blockchain Tables in 21c and found them useful but constrained, Version 2 is worth a serious look. If you’ve been skeptical because the first version felt underbuilt, the 23c additions address most of the specific complaints I heard from people who evaluated it earlier.
