Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 

CUBRID Characteristics

Transaction Support

CUBRID supports the following features to completely ensure the atomicity, consistency, isolation and durability in transactions.

  • Supporting commit, rollback, savepoint per transaction
  • Ensuring transaction consistency in the event of system or database failure
  • Ensuring transaction consistency between replications
  • Supporting multiple granularity locking of databases, tables and records
  • Resolving deadlocks automatically
  • Supporting distributed transactions (two-phase commit)
Database Backup and Restore

A database backup is the process of copying CUBRID database volumes, control files and log files; a database restore is the process of restoring the database to a certain point in time using backup files, active logs and archive logs copied by the backup process. For a restore, there must be the same operating system and the same version of CUBRID installed as in the backup environment.
The backup methods which CUBRID supports include online, offline and incremental backups; the restore methods include restore using incremental backups as well as partial and full restore.

Table Partitioning

Partitioning is a method by which a table is divided into multiple independent logical units. Each logical unit is called a partition, and each partition is divided into a different physical space. This will lead performance improvement by only allowing access to the partition when retrieving records. CUBRID provides three partitioning methods:

  • Range partitioning: Divides a table based on the range of a column value
  • Hash partitioning: Divides a table based on the hash value of a column
  • List partitioning: Divides a table based on the column value list
Supports a Variety of Index Functions

CUBRID supports the following index functions to utilize indices while executing a variety of conditional queries.

  • Descending Index Scan: Descending Index Scan is available only with Ascending Index Scan, without creating separate reverse indexes.
  • Covering Index: When the column of a SELECT list is included in the index, the requested data can be obtained with an index scan.
  • ORDER BY Clause Optimization: If the required record sorting order is identical to the order of indices, no additional sorting is required (Skip ORDER BY).
  • GROUP BY Clause Optimization: If all columns in the GROUP BY clause are included in the indices, they are available to use while executing queries. Therefore, no additional sorting is required (Skip GROUP BY).

CUBRID provides High Availability (HA) to minimize system down time while continuing normal operation of server in the event of hardware, software, or network failure. The structure of CUBRID HA is shared-nothing. CUBRID monitors its system and status on a real time basis with the CUBRID Heartbeat and performs failover when failure occurs. It follows the two steps below to synchronize data from the master database server to slave database server.

  1. A transaction log multiplication step where the transaction log created in the database server is replicated in real time to another node
  2. A transaction log reflection step where data is applied to the slave database server through the analysis of the transaction log being replicated in real time
Java Stored Procedure

A stored procedure is a method to decrease the complexity of applications and to improve the reusability, security and performance through the separation of database logic and middleware logic. A stored procedure is written in Java (generic language), and provides Java stored procedures running on the Java Virtual Machine (JVM). To execute Java stored procedures in CUBRID, the following steps should be performed:

  1. Install and configure the Java Virtual Machine
  2. Create Java source files
  3. Compile the files and load Java resources
  4. Publish the loaded Java classes so they can be called from the database
  5. Call the Java stored procedures
Click Counter

In the Web, it is a common scenario to count and keep the number of clicks to the database in order to record retrieval history.

The above scenario is generally implemented by using the SELECT and UPDATE statements; SELECT retrieves the data and UPDATE increases the number of clicks for the retrieved queries.

This approach can cause significant performance degradation due to increased lock contention for UPDATE when a number of SELECT statements are executed against the same data.

To address this issue, CUBRID introduces the new concept of the click counter that will support optimized features in the Web in terms of usability and performance, and provides the INCR function and the WITH INCREMENT FOR statement.

Extending the Relational Data Model


For the relational data model, it is not allowed that a single column has multiple values. In CUBRID, however, you can create a column with several values. For this purpose, collection data types are provided in CUBRID. The collection data type is mainly divided into SET, MULTISET and LIST; the types are distinguished by duplicated availability and order.

  • SET : A collection type that does not allow the duplication of elements. Elements are stored without duplication after being sorted regardless of their order of entry.
  • MULTISET : A collection type that allows the duplication of elements. The order of entry is not considered.
  • LIST : A collection type that allows the duplication of elements. Unlike with SET and MULTISET, the order of entry is maintained.


Inheritance is a concept to reuse columns and methods of a parent table in those of child tables. CUBRID supports reusability through inheritance. By using inheritance provided by CUBRID, you can create a parent table with some common columns and then create child tables inherited from the parent table with some unique columns added. In this way, you can create a database model which can minimize the number of columns.


In a relational database, the reference relationship between tables is defined as a foreign key. If the foreign key consists of multiple columns or the size of the key is significantly large, the performance of join operations between tables will be degraded. However, CUBRID allows the direct use of the physical address (OID) where the records of the referred table are located, so you can define the reference relationship between tables without using join operations.

That is, in an object-oriented database, you can create a composition relation where one record has a reference value to another by using the column displayed in the referred table as a domain (type), instead of referring to the primary key column from the referred table.