Skip to content
immudb docker run -d -p 3322:3322 -p 8080:8080 -it --name immudb codenotary/immudb:latest

Blog

Oracle Blockchain Tables or immudb? Keep the Transactional Database Transactional

  • immudb
  • oracle
  • architecture
  • audit-log
  • immutability

Oracle AI Database includes Blockchain Tables, giving Oracle users a way to create append-only, cryptographically chained records inside the same database that handles their normal transactional workloads. The capability is technically sophisticated. The architectural question, however, is whether immutability should be added as a special mode inside the transactional database — or handled by a database designed specifically for immutable data.

For many applications, the simpler architecture is: keep Oracle for OLTP and send records that must be independently tamper-evident to immudb.

Oracle Blockchain Tables or immudb — keep the transactional database transactional

What an Oracle Blockchain Table actually asks of you#

Oracle Blockchain Tables require developers and DBAs to understand a separate set of table semantics. A current Oracle AI Database blockchain table might look like this:

 1CREATE BLOCKCHAIN TABLE audit_events (
 2    event_id        NUMBER,
 3    account_id      NUMBER,
 4    event_type      VARCHAR2(64),
 5    event_data      VARCHAR2(4000),
 6    created_at      TIMESTAMP
 7)
 8NO DROP UNTIL 31 DAYS IDLE
 9NO DELETE LOCKED
10HASHING USING SHA2_512 VERSION V2;

Those clauses are not decorative. Oracle requires specific blockchain-table retention and hashing rules. NO DELETE LOCKED, for example, permanently prevents row deletion, while NO DROP UNTIL ... IDLE controls when the table itself may be dropped. Oracle also distinguishes V1 and V2 blockchain formats, and a table cannot simply be converted between those versions later.

Internally, Oracle creates additional hidden ORABCTAB_* columns containing chain identifiers, sequence information and cryptographic hashes. Each inserted row incorporates the hash of an earlier row, producing tamper evidence.

That works, but it means the Oracle estate now contains two substantially different classes of data: ordinary mutable relational data and blockchain-managed data, with different lifecycle, deletion and administration rules.

Business state and evidence are not the same workload#

Consider an order-processing system. Oracle remains an excellent place for the operational record:

 1CREATE TABLE orders (
 2    order_id       NUMBER PRIMARY KEY,
 3    customer_id    NUMBER,
 4    status         VARCHAR2(20),
 5    total          NUMBER(12,2)
 6);
 7
 8UPDATE orders
 9SET status = 'SHIPPED'
10WHERE order_id = 912837;

Orders naturally change. Addresses change. Status changes. Payments may be reversed. Transactional systems need UPDATE, DELETE, constraints, joins and mature transaction processing.

An immutable audit event has almost exactly the opposite requirement.

Writing the evidence to immudb instead#

Instead of turning part of Oracle into a different kind of database, the application can write the business transaction to Oracle and the evidence to immudb:

1CREATE TABLE audit_events (
2    id INTEGER AUTO_INCREMENT,
3    order_id INTEGER,
4    event VARCHAR,
5    actor VARCHAR,
6    created_at TIMESTAMP,
7    PRIMARY KEY id
8);

Then:

1INSERT INTO audit_events
2    (order_id, event, actor, created_at)
3VALUES
4    (912837, 'ORDER_SHIPPED', 'warehouse-17', NOW());

There is no special BLOCKCHAIN table type to configure. Immutability is a property of the database architecture itself. immudb permits new transactions and new versions while protecting historical transactions against modification or deletion.

Verification the client can perform itself#

The distinction becomes even more important when verification matters.

With Oracle Blockchain Tables, cryptographic chaining is implemented and maintained by Oracle inside Oracle Database. With immudb, verification is exposed to clients. SDK operations such as VerifiedGet obtain cryptographic proofs from the server and verify them client-side. A client therefore does not have to rely exclusively on the database server’s assertion that history is intact.

Conceptually:

1value, err := client.VerifiedGet(ctx, []byte("audit:912837"))
2if err != nil {
3    log.Fatal(err)
4}

The application consuming the evidence can participate in verifying its integrity.

The operational case for separation#

There is also an operational advantage to separation. The Oracle DBA can continue treating Oracle as Oracle: tune indexes, manage schemas, upgrade applications and operate transactional workloads without introducing unusual retention rules into selected tables.

immudb can meanwhile have a narrowly defined responsibility:

 1Oracle AI Database
 2    |
 3    +-- customers
 4    +-- orders
 5    +-- inventory
 6    +-- payments
 7           |
 8           | security/audit events
 9           v
10        immudb
11    +-- audit trail
12    +-- compliance evidence
13    +-- signatures
14    +-- software provenance

This is classic separation of concerns.

One question, not a new table type#

Oracle Blockchain Tables are an impressive solution when an organization insists that immutable records remain entirely inside Oracle. But using the same database engine for both mutable business state and immutable evidence is not automatically simpler simply because everything carries the Oracle logo.

For systems already running Oracle, the cleaner design can be surprisingly straightforward: let Oracle do what Oracle does exceptionally well — transaction processing — and let immudb do what it was designed to do — preserve and cryptographically verify history.

Instead of adding blockchain semantics to every application that needs trustworthy records, developers simply decide one thing:

Is this business state, or is this evidence?

Business state goes to Oracle.

Evidence goes to immudb.

Ready to try it? Start with running immudb , then connect from your language with the official SDKs and read up on the immutable audit log .