Relational NT is an experimental database kernel inspired by the object-management model of the Windows NT kernel. The project applies explicit object management to database state: relations, tuples, transactions, namespaces, permissions, cursors, and handles are runtime-managed objects rather than isolated subsystems.
Motivation
The NT kernel is a good model for a dedicated database kernel for three reasons.
The object manager. NT's OB gives every kernel resource a named path, a security descriptor, and a uniform open/close lifecycle enforced through handles. A database kernel has the same requirements. Rather than building those mechanisms independently for each database concept, this project borrows the NT object manager's shape directly.
Physical backends as drivers. NT device drivers expose a narrow dispatch table. The kernel routes I/O through it without knowing whether the device is a local disk or a network adapter. Storage backends here follow the same pattern. A remote backend like etcd is just another driver, but brings its own concerns: network latency, connection management, and the possibility of partial failure. The driver boundary keeps those concerns inside the backend module.
Clients as environment subsystems. NT supports Win32, POSIX, and OS/2 as environment subsystems layered above a common native API. A database client works the same way: a PostgreSQL wire adapter, a MySQL wire adapter, or an HTTP/JSON interface each translates its protocol into kernel-level operations. The kernel never sees SQL syntax or protocol framing.
Architecture
- ObjectManager registers, locates, and references database objects by logical path.
- PermissionsManager keeps capability checks separate from object lookup.
- IdentityManager decides whether an object supports a requested lifecycle operation.
- LifecycleManager models monitoring, pinning, cleanup, and contention.
- HandlerManager orchestrates the full open/close workflow and owns handle allocation.
- CursorManager provides a pull-based iterator over storage, abstracting pagination, snapshot pinning, and scan boundaries.
- VM separates terminating first-order relational retrieval (Tarski) from higher-order logic execution (Karuta).
- NamespaceReferenceManager handles logical path mapping and namespace isolation, including private branch shadowing and atomic multi-reference updates.
Building
Requires MSVC, CMake 3.10 or later, and vcpkg. Dependencies are fetched automatically during configure.
A release build uses --preset x64-release.
Generating Documentation
Generated HTML is written to docs/generated/html.
