DBX4: A Database Engine Where Attribution, Workflow and Approval Live in the Core

DBX4 is a relational database engine written from scratch in C++ with no third-party dependencies. It was built to explore a single question: what would a database look like if the engine understood that a row is a business record — something that must be attributable, approvable, and connected to other records — rather than an anonymous tuple.

This article covers what DBX4 does, how it was built, and the engineering decisions behind it.

What DBX4 Is

DBX4 is a single-binary engine of roughly 6,800 lines of C++17. It compiles with one command and links nothing but the standard library. It runs as a shell, a TCP server, or an HTTP service, and stores a database as a single portable file.

It supports three query languages over one parser — SQL, a pipeline dialect (DQL), and a bracket dialect (BQL) — along with transactions, write-ahead logging with crash recovery, B-tree and vector indexes, blockchain-style tamper-evident tables, and rich types including CLOB, XML, BLOB and JSON.

None of that is unusual. The parts worth writing about are the three that treat a row as a business record.

Attribution Is Not Optional

Declare a table WITH PERFORMER and the engine maintains five columns itself:

The first four are conventional. The fifth is the one that matters. If someone corrects fifteen part numbers during a single login, updated_by says the same name fifteen times and the timestamps sit seconds apart. Reconstructing what that sitting actually touched means reading timestamps and guessing.

DBX4 mints an id at login — EV-20260715040102-jsmith-1 — and stamps it on every row that session writes. The question becomes a query rather than an investigation:

SELECT * FROM po WHERE event_id = 'EV-20260715040102-jsmith-1';

Creation stamps never move. An update touches updated_* and re-stamps event_id, so the row always names the session that last changed it. Because the engine owns the columns, there is no code path that bypasses them — not a bulk import, not an admin script.

Events Are Workflow, Not Audit

An event in DBX4 is not a trigger that logs something. It is the workflow itself: a shipment relieves inventory, which books COGS, which hits the GL, which rolls into P&L. Real chains run four to six levels deep.

Two design decisions came out of testing that:

• Events are fire-and-forget, but nothing is lost. The emitter writes the event to a

durable queue and returns; a background listener runs the cascade. The user's insert does not wait for the accounting. Delivery is at-least-once, with retry, and anything that cannot be delivered lands in a dead-letter list an operator can see.

• A failed event quarantines its flow. When a critical event dead-letters, new inserts

into that table are refused so the damage cannot compound — while UPDATE and DELETE stay open, because that is how you repair. Once the exception is resolved the flow reopens by itself.

Exceptions are addressable individually, in the manner of Oracle's Workflow Administrator: SHOW EVENT ERRORS lists each one with its id, the failing SQL, the performer and the session; RETRY EVENT 3 re-drives one; SKIP EVENT 3 'reason' abandons one. A skip demands a reason and is recorded permanently — an unexplained gap in the books is worse than a visible, owned one.

Approval Comes From the Person, Not the Document

Approval limits and reporting lines live on the user:

GRANT APPROVAL LIMIT 50000 TO alice;
SET MANAGER OF alice TO bob;
CREATE TABLE po (id INT PRIMARY KEY, item TEXT, amount INT) WITH APPROVAL (amount);

A purchase order above the submitter's limit lands PENDING and routes to the first person up the line whose limit covers it. The ordering is the whole point: a pending row raises no events. Without that, an unapproved PO would book its commitment the moment it was keyed in. Approval releases the held events; rejection means they never fire.

The guards are the ones an auditor asks about. A submitter cannot approve their own row even if their limit is later raised to cover it. Authority is re-checked at the moment of approval, not at routing time. If nobody in the reporting line can approve an amount, the insert is refused outright rather than passing silently.

Technical Architecture

The engine carries 257 automated tests. Most of them exist because they caught something: a cascade that silently truncated at four levels and left the books unbalanced; a statement splitter that broke on a part described as Bolt; M8; an approval gate that vanished on restart because its flag was never written to the catalog.

What It Is Not

DBX4 is a personal research project, not a product. It is not a replacement for Postgres, Oracle or SQLite, and it is not close to them on the things that actually matter for production — replication, security hardening, tooling, or the twenty years of failure modes those engines have already found.

It is a single-node engine. The MVCC layer is not yet wired to the SQL executor. Approvals are limit-and-hierarchy based, not a rules engine. Encryption is designed but not built. There is no ecosystem, and there will not be one.

What it is: a working demonstration that attribution, workflow and approval belong in the engine rather than bolted on above it — and a body of evidence, in the form of tests, for what breaks when they are not.

*DBX4 is a personal project by DhirajKumar Pathak. Built for evaluation and learning purposes. Not a commercial product.*

Comments (0)