Differences between DBMS «Quantum Hybrid Base» and PostgreSQL

Benefits of DBMS «Quantum Hybrid Base»

DBMS «Quantum Hybrid Base» (QHB) is a deep fork of the open-source solution PostgreSQL and provides

  • compatibility by access protocols;
  • compatibility (one-sided) by data formats;
  • compatibility (one-sided) by functionality and built-in extensions;
  • compatibility with external extensions (when reassembling and/or fixing dependencies).

DBMS «Quantum Hybrid Base» is a completely domestic solution

  • registered in the Russian Software Registry, No. 6212 since April 7, 2020;
  • certified by the Federal Service for Technical and Export Control (FSTEC Certificate No. 4691 dated July 12, 2023);
  • the encryption module is registered in the Russian Software Registry, No. 21868;
  • the encryption module is certified by the Federal Security Service of the Russian Federation (FSB Certificate No. SF/124-4721 dated January 15, 2024);
  • developer is a totally Russian company;
  • stabilized solution (several stable releases have been released, the current release is 1.5.3);
  • professional team of developers with many years of experience;
  • professional technical support;
  • the possibility of modification "on request", including:
    • in a much shorter time frame compared to open-source solutions and other forks;
    • with very deep integration into the DBMS core.

Note
FSTEC and FSB certificates — for the certified version of DBMS «Quantum Hybrid Base»


Main directions of DBMS modification

1. Increased stability, sustainability, productivity

1.1. Network load balancer and connection pooler

See QCP for details.

  • asynchronous operation mode;
  • threaded model;
  • session-level dividing modes and intelligent mode (session dividing between multiple read-only connections);
  • automatic switching to standby nodes.

1.2. Disk block cache manager

See TARQ for details.

  • resistance to cache leaking;
  • minimization of "cache warm-up" time;
  • ability to build In-Memory and Append-only tables.

1.3. Refactoring of many DBMS core modules, elimination of vulnerabilities, rewriting in Rust language.


2. Built-in cryptographic data protection

See QSS for details.

  • on domestic certified algorithms ГОСТ Р 34.13-2015, ГОСТ 34.13-2018, ГОСТ Р 34.12-2015, ГОСТ 34.12-2018, ГОСТ Р 34.11-2012, ГОСТ 34.11-2018 and standards Р 1323565.1.026–2019, Р 50.1.111-2016, Р 50.1.113-2016;
  • page-level data encryption, including WAL/replication logs and binary backups;
  • encryption at the level of all or individual tables;
  • without noticeable/significant performance decrease.

3. Increasing solution maintainability, reducing operational risks

3.1. Monitoring database activity

See Chapter Monitoring Database Activity for details.

  • metric collection system that deeply integrated into the core;
  • virtually no impact on performance (the duration of reading one reading is ~30 ns);
  • the number of metrics is several times greater than the standard PostgreSQL metrics (including real-time session state and query execution step indicators);
  • aggregation/export/visualization on the same or neighboring host (without load on the main server);
  • it is possible for user to enable/disable metric collection as desired.

3.2. Backup Tool

See qbackup for details.

  • binary full and incremental backups without stopping the instance;
  • parallel multi-threaded backups;
  • backup compression;
  • remote backups;
  • accelerated recovery (faster than WAL replay);
  • point-in-time recovery;
  • maintaining a backup catalog (as text or JSON);
  • tracking changed data, or CDC (change data capture);
  • creating backups by tablespaces;
  • validating backups;
  • the ability to delete WAL files when deleting a backup.

4. Development of features missing from the open-source solution:

4.1. Built-in message queue

See Built-in Message Queue for details.

  • persistent messages;
  • In-Memory messages.

4.2. Built-in task scheduler

See QSched for details.

  • creating and managing schedules/tasks;
  • maintaining scheduler logs;
  • enabling/disabling dynamic calculation of the next execution time;
  • managing parallel scheduler processes.

4.3. Session level variables

See qhb-variables for details.

  • scalar variables;
  • table variables, integration with table items.

4.4. Profiling long queries

See Profiling Long Queries for details.

4.5. Direct data loading module

See QDL for details.

  • ability to speed up data loading by approximately 3 times (compared to the COPY command);
  • compatibility with CDC;
  • API for loading data.

4.6. External storage of large binary data (blob/clob/bytea)

See Rbytea for details.

4.7. Extension for implementing a bitemporal data model

See Qbim for details.

4.8. Statistical analysis methods based on Bayesian conditional probabilities

See Qbayes for details.

4.9. Support for 1C solutions in the DBMS core; compatibility confirmed by 1C

See 1C Solution Support, Confirmation by "1C" for details.

4.10. Advanced XML Functions (to support migration from Oracle)

See Advanced XML Functions for details.

4.11. QMiM tools for supporting migration from Oracle and MSSQL DBMS (in pilot operation, as a separate solution)

4.12. Extension for implementing dumping and restoring the contents of the pg_statistic table

See stat_dump for details.

4.13. Shared Plan Cache

See Shared Plan Cache for details.

The shared plan cache saves CPU time by storing SQL query execution plans in shared memory rather than regenerating them.

4.14. Autonomous Transactions

See Autonomous Transactions for details.

Autonomous transactions provide a special way to manage transactions in stored procedures. An autonomous transaction is a subtransaction isolated from its parent transaction. Autonomous transactions can commit (COMMIT) or rollback (ROLLBACK) changes, regardless of the outcome of the parent transaction.

4.15. Qluster — Cluster Computing Management Module

See Qluster for details.

A software module designed for managing distributed tasks in a cluster. Qluster is based on the QRaft state coordination protocol, which ensures consistency and fault tolerance of cluster operations.

4.16. Qman — Application for Monitoring and Managing QHB Instances.

See [Qman] for details.

The Qman interface application (QHB Manager) is designed for monitoring and managing QHB instances and clusters. It includes an interface module, a Qman agent, a REST/SQL API, a central repository, and scripts for executing queries and commands.


Links