What are the characteristices of the two new Oracle database table types Blockchain and Immutable?  What about the differences and use cases? Briefly explained, it’s about special tables intended for unchangeable (= immutable) usage i.e. they can only be used for INSERT-only operations and – depending on the type selected – provide additional protection and security. This opens a wide field of new possibilities for applications with the Oracle database.  

Why two different table types? Immutable tables in Oracle database are read-only tables that prevent unauthorized data modifications by insiders and accidental data modifications resulting from human errors. Unauthorized modifications can be attempted by compromised or rogue employees who have access to insider credentials. New rows can be added to an immutable table, but existing rows cannot be modified. You must specify a retention period both for the immutable table and for rows within the immutable table. Rows become obsolete after the specified row retention period. Only obsolete rows can be deleted from the immutable table.

Blockchain tables are insert-only tables that organize rows into a number of chains. Each row in a chain, except the first row, is chained to the previous row in the chain by using a cryptographic hash. The hash value of a row is calculated based on the row data and the hash value of the previous row in the chain, so that any possible modification and manipulation of a row can be detected or checked with a special verification procedure. The possibility to additionally store user signatures increases the security against manipulations. Immutable Tables however do not possess these additional safety mechanisms such as hashing and signatures. Thus, they represent a “trimmed down” form of the blockchain table type.

A short comparison of the properties can also be found in the Administrator’s Guide (see table Table 19-8 Differences Between Immutable Tables and Blockchain Tables).
Update 2025: The enhancements of 23ai blockchain tables can be found here.

Creation and Monitoring

Both table types are intended for immutable, INSERT-only tables. Both table types are implemented using the Hidden Columns functionality in Oracle Database but have their own package and data dictionary view infrastructure. The following example shows a BLOCKCHAIN table creation in Oracle Database.  The NO DROP clause determines how long the table is protected from being dropped – in our case 1 day. The NO DELETE clause determines the retention period. How long each row will be protected from deletion.

Note:

  • Blockchain tables cannot be created in the root container and in an application root container. The COMPATIBLE initialization parameter must be set to 19.10.0.0 or higher to create a V1 blockchain table and 23.0.0.0 or higher to create a V2 blockchain table.
  • You must specify the version when you create a blockchain table, either V1 or V2. Version V2 creates additional Oracle managed hidden columns than V1. 
SQL> CREATE BLOCKCHAIN TABLE BLOCKC_v1 (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT
     HASHING USING "SHA2_512" VERSION v1;
Table created 

SQL> CREATE BLOCKCHAIN TABLE BLOCKC_v2 (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT
     HASHING USING "SHA2_512" VERSION v2;
Table created.

Please check out the CREATE TABLE clause here.

SQL> SELECT table_name, column_name, nullable, hidden_column
     FROM  all_tab_cols
     WHERE  table_name like 'BLOCKC_V%' ORDER BY column_id;

TABLE_NAME      COLUMN_NAME                                       NUL HIDDEN_CO
--------------- ------------------------------------------------- --- ---------
BLOCKC_V2       TEST                                              Y   NO
BLOCKC_V1       TEST                                              Y   NO
BLOCKC_V2       T                                                 Y   NO
BLOCKC_V1       T                                                 Y   NO
BLOCKC_V1       ORABCTAB_SIGNATURE_ALG$                           Y   YES
BLOCKC_V2       ORABCTAB_CHAIN_ID$                                Y   YES
BLOCKC_V2       ORABCTAB_CREATION_TIME$                           Y   YES
BLOCKC_V2       ORABCTAB_SPARE$                                   Y   YES
BLOCKC_V1       ORABCTAB_USER_NUMBER$                             Y   YES
BLOCKC_V1       ORABCTAB_HASH$                                    Y   YES
BLOCKC_V2       ORABCTAB_COUNTERSIGNATURE_CERT$                   Y   YES
BLOCKC_V1       ORABCTAB_SPARE$                                   Y   YES
BLOCKC_V2       ORABCTAB_SIGNATURE_CERT$                          Y   YES
BLOCKC_V2       ORABCTAB_COUNTERSIGNATURE$                        Y   YES
BLOCKC_V1       ORABCTAB_SIGNATURE_CERT$                          Y   YES
BLOCKC_V2       ORABCTAB_USER_NUMBER$                             Y   YES
BLOCKC_V2       ORABCTAB_USER_CHAIN_HASH$                         Y   YES
BLOCKC_V2       ORABCTAB_COUNTERSIGNATURE_ALG$                    Y   YES
BLOCKC_V1       ORABCTAB_SIGNATURE$                               Y   YES
BLOCKC_V2       ORABCTAB_ROW_VERSION$                             Y   YES
BLOCKC_V2       ORABCTAB_INST_ID$                                 Y   YES
BLOCKC_V2       ORABCTAB_HASH$                                    Y   YES
BLOCKC_V2       ORABCTAB_TS$                                      Y   YES
BLOCKC_V2       ORABCTAB_DELEGATE_SIGNATURE$                      Y   YES
BLOCKC_V2       ORABCTAB_DELEGATE_SIGNATURE_ALG$                  Y   YES
BLOCKC_V2       ORABCTAB_DELEGATE_SIGNATURE_CERT$                 Y   YES
BLOCKC_V2       ORABCTAB_COUNTERSIGNATURE_ROW_FORMAT_VERSION$     Y   YES
BLOCKC_V2       ORABCTAB_COUNTERSIGNATURE_ROW_FORMAT_FLAG$        Y   YES
BLOCKC_V1       ORABCTAB_SEQ_NUM$                                 Y   YES
BLOCKC_V2       ORABCTAB_SIGNATURE$                               Y   YES
BLOCKC_V1       ORABCTAB_INST_ID$                                 Y   YES
BLOCKC_V2       ORABCTAB_LAST_ROW_VERSION_NUMBER$                 Y   YES
BLOCKC_V2       ORABCTAB_SIGNATURE_ALG$                           Y   YES
BLOCKC_V1       ORABCTAB_CREATION_TIME$                           Y   YES
BLOCKC_V1       ORABCTAB_CHAIN_ID$                                Y   YES
BLOCKC_V2       ORABCTAB_DELEGATE_USER_NUMBER$                    Y   YES
BLOCKC_V2       ORABCTAB_SEQ_NUM$                                 Y   YES
BLOCKC_V2       ORABCTAB_PDB_GUID$                                Y   YES
38 rows selected.    
 
SQL> select * from dba_blockchain_tables;

SCHEMA_NAME
--------------------------------------------------------------------------------
TABLE_NAME      ROW_RETENTION ROW_RETEN TABLE_INACTIVITY_RETENTION
--------------- ------------- --------- --------------------------
HASH_ALGORITHM           TABLE_VERSION         CURRENT_EPOCH MAX_SYSTEM_CHAINS
------------------------ --------------------- ------------- -----------------
DELETE_TIME
---------------------------------------------------------------------------
SCOTT
BLOCKC_V1                  16 NO                                 1
SHA2_512                 V1                                1                32


SCOTT
BLOCKC_V2                  16 NO                                 1
SHA2_512                 V2                                1                32

SQL> insert into blockc_v1 values ('test', 1);
1 row created.
SQL> commit;
Commit complete.

Blockchain tables contain system-generated hidden columns. In the following example the content of th hidden columns is also shown.

SQL> SELECT test, t,
ORABCTAB_SPARE$,ORABCTAB_USER_NUMBER$, ORABCTAB_HASH$,
ORABCTAB_SIGNATURE$, ORABCTAB_SIGNATURE_ALG$, ORABCTAB_SIGNATURE_CERT$,
ORABCTAB_SEQ_NUM$, ORABCTAB_CHAIN_ID$, ORABCTAB_INST_ID$, ORABCTAB_CREATION_TIME$
FROM blockc_v1;

TEST
--------------------------------------------------------------------------------
         T
----------
ORABCTAB_SPARE$
--------------------------------------------------------------------------------
ORABCTAB_USER_NUMBER$
---------------------
ORABCTAB_HASH$
--------------------------------------------------------------------------------
ORABCTAB_SIGNATURE$
--------------------------------------------------------------------------------
ORABCTAB_SIGNATURE_ALG$ ORABCTAB_SIGNATURE_CERT$         ORABCTAB_SEQ_NUM$
----------------------- -------------------------------- -----------------
ORABCTAB_CHAIN_ID$ ORABCTAB_INST_ID$
------------------ -----------------
ORABCTAB_CREATION_TIME$
---------------------------------------------------------------------------
test
         1

                  136
556BC29D35C670F311A03FEA5F37B0E6B8209E9CEAAFF986009256383BAE4BAF93937EC3D8C338E1
846EDF25780C58A930AB42DCA46DD4F87A6D44A9BC77AA38

                                                                         1
                19                 2
22-MAY-25 10.23.27.712315 AM +00:00

Now we create an immutable table. Immutable tables contain also system-generated hidden columns. The columns are the same as those for blockchain tables however only two hidden columns are used for the implementation. 

SQL> CREATE IMMUTABLE TABLE test_immutable (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT; 
Table created.

Note: If you do not specify the VERSION using immutable_data_format_clause, a V1 immutable table is created by default.

 
SQL> insert into test_immutable values ('I1',1);
1 row created.

SQL> commit;
Commit complete.

SQL> select * from dba_immutable_tables;

SCHEMA_NAME
--------------------------------------------------------------------------------
TABLE_NAME      ROW_RETENTION ROW_RETEN TABLE_INACTIVITY_RETENTION
--------------- ------------- --------- --------------------------
TABLE_VERSION         CURRENT_EPOCH
--------------------- -------------
DELETE_TIME
---------------------------------------------------------------------------
SCOTT
TEST_IMMUTABLE             16 NO                                 1
V1                                1

Operations 

How can you work with the new table types? Which Operations are allowed and which one are blocked? In general normal database and regular tables can be mixed in queries and transactions. A blockchain table can be dropped if it contains no rows or after it has not been modified for a period of time that is defined by its retention period.  In general operations like UPDATE, MERGE and changes to columns are not allowed according to the definition. Deleting rows, on the other hand, can be enabled if the NO DELETE UNTIL clause has been used. To delete rows you need to use the package DBMS_IMMUTABLE_TABLE or in the case of Blockchain Tables DBMS_BLOCKCHAIN_TABLE. Other Oracle database operations are possible – including the creation of views and indexes, partitioning and much more. All “standard” data types are supported; however, data types such as Object Types, BFILE, XMLTYPE, etc. are not supported. There are also restrictions on the use of DIRECT PATH LOADs, Flashback Table or Oracle Data Pump. BLOCKCHAIN and IMMUTABLE tables are exported and imported as regular tables. 
More information on restrictions and limitations are listed in the documentation see

Restrictions for Immutable Tables 
Restrictions for Blockchain Tables

In case of Blockchain Tables there are some additional functions provided by the PL/SQL interface DBMS_BLOCKCHAIN_TABLE. For example a current user can work with the SIGN_ROW procedure to provide a signature on row content of a previously inserted row. A complete example how to use this functionality can be found in our posting Blockchain inside Oracle Database. (It is written in German however the code snippets are easy to understand and can be copied.)
With VERIFY_TABLE_BLOCKCHAIN procedure you can verify all rows and return the number of successfully verified rows. VERIFY_ROWS Verifies all rows on all applicable chains for integrity of HASH column value and optionally the SIGNATURE column value for rows created in the range of low_timestamp to high_timestamp. An appropriate exception is thrown if the integrity of chains is compromised.

Availability

Both table types are features of Oracle Database release 21c and are backported to 19c. They are also available in Autonomous Database 19c. If you want to use the technologies in 19c on premises or Cloud VM, at least the release update 19.10 for Blockchain and 19.11 for Immutable Tables is required. Keep in mind that the COMPATIBLE parameter must be changed for this. Otherwise, you will receive the following error message in the case of blockchain tables, for example:

SQL> CREATE BLOCKCHAIN TABLE test_blockchain
     (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 days after INSERT
     HASHING USING "SHA2_512" VERSION "v1"; 

CREATE BLOCKCHAIN TABLE test_blockchain
*
ERROR at line 1:
ORA-00406: COMPATIBLE parameter needs to be 19.10.0.0.0 or greater
ORA-00722: Feature "Blockchain table"

The COMPATIBLE initialization parameter must be set to 19.10.0.0 or higher to create a V1 blockchain table and 23.0.0.0 or higher to create a V2 blockchain table. Blockchain tables cannot be created in the root container and in an application root container.  You must specify the version when you create a blockchain table, either V1 or V2. Version V2 creates additional Oracle managed hidden columns than V1. Version V2 creates additional Oracle managed hidden columns than V1.

Conclusion

Immutable and Blockchain Tables are important features in Oracle Converged Database. They are free of charge. You can store and manage blockchain or insert-only applications centrally in the database. If it is only about the unchangeability of the tables, you should use the Immutable table type. In this case fewer hidden columns are used and therefore less resources and processing time are needed, and you can expect better performance when loading data. Blockchain tables however can be used to implement blockchain applications where the participants trust the Oracle Database, but want a means to verify that their data has not been tampered. 

More information