Database engines are usually discussed as products with compatibility claims: which dialect is supported, which wire protocol is spoken, what does a backup restore. QuantsMind Relational DB is more interesting read as a kernel. Its organising decision is to build a general storage kernel first — key-value storage, indexes, multi-version concurrency control and a write-ahead log — and treat the relational model as one layer on top. That layering explains both what it does well and where its limits are, because a general kernel can be extended with new models without rewriting, and can also carry complexity that a single-purpose engine would never take on.
The kernel-first design
The core is a storage kernel rather than a table engine. It provides key-value storage with indexes, multi-version concurrency control, and a write-ahead log. Relational, document and key-value access patterns are then model layers built on that substrate, which means a new data model is an additive feature rather than a rewrite. The project also targets hybrid transactional and analytical workloads from the outset: the row store serves online transaction processing, while a persistent columnar replica is intended to serve analytical reads.
The engine is explicit about its priorities. Correctness is stated as the governing concern — the concurrency control and recovery paths are fuzzed and property-tested, on the stated principle that silent corruption is the one unacceptable bug — and performance is treated as a contract, meaning each milestone carries numeric exit criteria enforced by benchmarks rather than aspirational targets. That is the right ordering for a database, and it is also why the current version can be described as feature-complete for its subset while still being explicitly experimental.
The supported SQL subset
The SQL layer is a handwritten parser feeding a Volcano-style iterator executor, which is the conventional design in which each operator is a node that produces rows on demand from the node below it. The documented surface covers table definition through CREATE TABLE and data manipulation through INSERT and SELECT. The operator set — sequential scan, filter, projection, limit, hash join and hash aggregation — is what a plan for those statements is built from.
Stating the subset explicitly matters more than it might appear. PostgreSQL compatibility is a property of a dialect and a wire protocol, not of an engine, and an engine that accepts a subset does not thereby become a PostgreSQL implementation. Code written for this engine should assume the documented subset and verify anything outside it.
Storage, transactions and recovery
Durability rests on a write-ahead log. Before a change is applied to the storage structures, the intended change is recorded in the log, so that a crash leaves a log that describes work which may not have reached the data files. Recovery replays that log. The recovery procedure rebuilds the catalog from the data-definition records in the log, redoes committed transactions, and recomputes the derived state — index entries in particular — that the redo pass depends on.
This is redo-only recovery without physical checkpoints, and it is the single most consequential limitation in the engine today. Because there are no periodic snapshots that bound the amount of work a restart must perform, recovery replays the log from the beginning of available history. Both physical checkpoints and log rotation are recorded in the project as planned rather than delivered work. For long-lived databases with large logs, that is a real operational constraint, not a footnote.
Embedding, server and desktop studio
The engine is packaged four ways because the intended uses differ. As a library it can be embedded directly, with the qmind-embed crate providing a JSON contract for host integration. As a server it listens for the PostgreSQL wire protocol over TCP and manages sessions, which is what makes ordinary drivers and the CLI usable. The CLI provides a shell for interactive work. And a native desktop studio gives a graphical environment for working with the same engine.
The desktop studio is a Tauri 2 application with a React front end, which is worth noting because it explains why the repository is not a pure Rust workspace: a graphical tool needs a front-end toolchain alongside it. For readers deciding how to deploy the engine, the practical guidance is that the server and library artefacts do not depend on any of the studio's web technology.
Differences from production databases
The distance between this engine and a production database is not primarily a feature list; it is a set of operational guarantees that have not yet been built. There are no physical checkpoints, so restart cost scales with the log. There is no replication, no failover and no high-availability story. The analytical path through the columnar replica is batched and, on the project's own description, not yet vectorised. A SQL subset without full conformance will reject queries that a PostgreSQL installation accepts, and no claim of complete PostgreSQL compatibility is made or demonstrated.
Conclusion
QuantsMind Relational DB is a real, embeddable engine with a thoughtful layering — a multi-version concurrency control and write-ahead log kernel underneath a relational model, wrapped for library, server, shell and desktop use. What it does today is executed well within a documented SQL subset. What it does not yet have is the operational durability layer a production database is assumed to provide, and the missing checkpoints are the most consequential of those gaps.