In-Memory Databases

In-memory databases are a distinct branch of x64base work: running the same DBF-family engine — tables, native CDX-V64 indexes, relations, scripts — entirely in RAM, with no change to the record, create, or loader code. Residency comes from swapping the substrate underneath the file layer, not from a parallel in-memory engine. This page is the section home; the operational command contract lives on RAM DBF and VDISK.

Evidence boundary. The VDISK / in-process RAM substrate below is implemented development source with runtime proof (AIF-043), visible in the local preview and not yet a tagged-release claim. Memo-resident MINIDB 1 save, inspection and RAM hydration now have development runtime evidence. Concurrent and nested multi-workspace management is Alpha -- proven, and still moving. Several workspaces are resident at once (R128, R130, additive OPEN and LOAD), containment is declared with depth and cycle rules (R137), and seven default-suite regressions cover the lane. What Alpha means here is that the surface is still changing, not that the behaviour is unproven. See Current Project Truth for the evidence order.

Two substrates

The initiative deliberately has two RAM substrates, chosen so the engine owns as much of the mechanism as possible.

The primary substrate is a self-owned in-process virtual filesystem (xbase::ramfs). It is the modern re-implementation of the 1980s RAMDRIVE.SYS / VDISK.SYS idea, but owned by the engine instead of the operating system — no signed kernel driver, no drive letter, and no third-party license to vet for redistribution. A process-global registry maps normalized absolute paths to growable byte buffers (RamFiles). The DBF and native-CDX file layers simply consult that registry: a virtual path reads and writes a RAM buffer, a real path uses the OS. Because the entire file stack runs unchanged, a table created in RAM behaves exactly like its on-disk twin — USE can reopen it and its sibling .cdx still resolves, since RAM files persist in the registry across stream open and close.

The optional add-on is LMDB-in-RAM via an operating-system symlink. LMDB must mmap a real OS file, so it cannot live in the in-process VFS. If a user wants LMDB-backed index environments in RAM as well, they opt into a symlink or junction that points the mem path slots at a real RAM volume — /dev/shm (tmpfs) on Linux with zero setup, or a driver-backed RAM disk on Windows. This is the only path that needs the vdisk.ini administrator configuration.

The VDISK lane

VDISK MOUNT redirects the DBF, INDEXES, and LMDB path slots beneath the RAM root (default <DATA>/ram) and mounts it as an in-process ramfs root. While mounted, CREATE X64, USE, and native CDX-V64 all live in RAM with nothing written to disk; VDISK STATUS and VDISK CONFIG report the live state; and VDISK UNMOUNT / OFF / CLEAR drop every resident RAM file. The lane is deliberately ephemeral — data that must survive belongs in a durable table or an explicit export. The full command and lifetime contract, owned by src/cli/cmd_vdisk.cpp, is documented on RAM DBF and VDISK.

Two-layer sizing and governance

The hard size limit belongs to the OS mount (tmpfs or a RAM-disk driver), which the engine did not create and cannot unilaterally resize. So sizing is split into two honest layers, per the AIF-043 spec (VDISK RAM Sizing & Admin Config v1).

Layer 1 is a provisioning recommendation — advisory, not enforced. In mode = auto the engine computes a suggested volume size as clamp(25% × available RAM, 64 MB floor, 2 GB ceiling), then caps it at 50% of total RAM so it never starves the host. A 16 GB machine with 10 GB free is advised 2 GB; a 4 GB machine with 1.5 GB free, 384 MB; a 1 GB machine with 300 MB free, 75 MB — degrading gracefully. VDISK CONFIG reports this number for an administrator or a provisioning script to act on.

Layer 2 is the engine's own soft budget — owned and enforced. The engine tracks used_bytes for files under the RAM root, warns at a high-water mark (warn_pct, default 80%), and applies an on_full policy at 100%: warn (let the OS write fail with a clear message), spill (fall back to the real-disk slot, converting RAM to disk), or fail. VDISK STATUS reports the live counter and resident-file count. This layer stays portable and honest even when the OS mount size is out of the engine's hands.

The vdisk.ini file ships inert — every line commented, so the feature is off until a user opts in. It is a true INI file (not a DotScript), read by its own [vdisk] parser with keys for enabled, root, mode, size_mb, percent, floor_mb, ceil_mb, warn_pct, and on_full.

MINIDB today; multi-workspaces next

Status: Alpha, with a split evidence boundary. Memo-resident MINIDB save, inspection and RAM hydration are runtime-proven in development. So are named concurrent workspaces and nesting: ownership, depth, cycle and close-order all have answers, and a 2026-08-21 descent opened a depth-2 container into 13 tables and 11 index containers. What remains directional is deeper recursion -- a container whose payload holds another container is chartered and untried, measured at at-rest depth of exactly one.

The design builds on the DTSHEMA workspace format (src/workspace/schema_workspace.cpp) and the payload-agnostic 64-bit memo reference (MemoRef, src/memo/memo_ref.cpp). MINIDB 1 carries the workspace posture plus raw DBF, CDX and carried DTX members as one binary-safe memo payload. The payload is the database, not metadata about one. It can be inspected, validated and hydrated into the RAM filesystem before the resulting database is opened in Workbench.

The next increment explores concurrent named workspaces with first-class area ownership and area budgeting. Each hydrated database needs an owned RAM subroot, area set, relation graph and lifecycle so identical table names do not collapse into one global namespace. A student's private database can travel inside a memo today; several hydrated instances can already be named, nested and navigated at once, and the open Alpha question is isolation -- cross-workspace name resolution, and a per-workspace RAM subroot.

The direction keeps explicit constraints: memos stay payload-agnostic (no privileged workspace-memo type), existing workspace forms remain compatible, and recursive ownership defines cycle, depth and teardown rules -- cycles are refused at creation, depth is computed at write time, and DESTROY retires only an empty, childless workspace. Resolution is the one still open.

Authority and provenance

The implemented substrate is owned by src/xbase/ramfs.cpp / include/xbase/ramfs.hpp (the in-process VFS) and src/cli/cmd_vdisk.cpp (the VDISK command), with sizing governed by the AIF-043 spec VDISK RAM Sizing & Admin Config v1. The original workspace / memo-resident direction is preserved as intake evidence under the development tree; the current capability boundary is maintained on Workspaces. See also FPT64 Memo Format, CDX and LMDB Indexing, and Current Work Lanes.