Workspaces

A workspace is the shape of a working session: which tables are open in which work areas, which index containers are attached, which tag orders are selected, what aliases they answer to, which relations are declared between them, and -- since version 3 -- where every cursor sat and which area was selected. It is the difference between "the data" and "how the data is currently arranged for work."

Alpha development boundary. Saved workspaces and memo-to-RAM MINIDB hydration are runtime-proven development capabilities. Concurrent, recursive and nested workspace management is active early work; it is discussed here as direction until its own runtime evidence and limits are recorded.

Workspaces are ordinary text or ordinary table rows. There is nothing proprietary in the middle.

The command surface

WORKSPACE SAVE <name> [MEMO] [V3] [MINIDB] and WORKSPACE LOAD <name> [MEMO] [RAM]. The trailing keywords are modifiers, combinable in either order, and every one of them is opt-in -- the bare forms behave exactly as they always have.

Two carriers, one format: the snapshot text is byte-identical whether it lands in a file or a memo field, because there is one serializer and one loader. A second writer would be a second truth, and the project has been bitten by exactly that before -- a parallel snapshot writer once claimed the same format version name for an incompatible layout, and reconciling it to a name of its own is recorded doctrine rather than a quiet cleanup.

Version 3, and why version 2 stays

Version 3 is a superset: same body, extra declarative lines. Older readers skip lines they do not recognize, so a v3 snapshot degrades rather than breaks, and v2 remains the default so every proven path keeps working untouched. What v3 adds:

• Measured flavor -- read from the open tables at save time, never declared by hand. Disagreement among areas is reported as mixed rather than averaged away.
• Its own roots -- the snapshot records the directories its tables and indexes live under, so a restore resolves against the payload's roots rather than whatever environment happens to be set. The standing proof deliberately points the engine at the wrong directories first; the workspace still stands up.
• Session state -- each area's physical record position and the selected area. On restore they are applied and then relations are refreshed, so children re-slave to the restored parent positions.

The catalog

Memo-carried workspaces live in WORKSPACES, a self-creating x64 table in the workspaces root. Each row records a unique id, the name, the display schema name, measured flavor, OS-compatibility claim, payload format, size, the areas it opens, recursion-guard fields, the id of the row it superseded, the author (a real member identity), the timestamp, and the roots active at save. Those columns form the envelope. The SNAPSHOT memo field carries the value: a posture for DTSHEMA rows, or the whole database container for MINIDB 1 rows. In the second case the row does not point to a database elsewhere; the row contains its raw DBF, CDX and carried DTX members. Saving again supersedes rather than overwrites, so the table keeps its own history -- and that lineage chain is, in practice, a commit log.

WORKSPACES.dbf is therefore heterogeneous by design: identity rows, posture rows and whole-database rows share one queryable outer table. Calling it only metadata misses the inversion that matters.

Every memo save is verified: the payload is read back through the token stored in the field -- not the one held in memory -- and byte-compared. A field-width truncation once slipped past a memory-side check; it cannot again.

Multiple workspaces and simultaneous use

Here the documentation has to be careful, because the honest answer has three parts.

What is true today. Several workspaces can be open at once. Since 2026-08-26 both WORKSPACE OPEN and WORKSPACE LOAD are additive: a load closes nothing, and a saved posture's area numbers are treated as keys rather than engine addresses, so its tables are placed into the current workspace wherever there is room. To get the old replacing behaviour you now compose it -- WORKSPACE CLOSE ALL then WORKSPACE OPEN <dir>.

This page said the opposite until 2026-09-02, and the engine's own WORKSPACE USAGE text has carried the dated correction since 08-27. The correction is recorded here rather than quietly swapped, because a reader who built a habit on the old sentence should be able to see that it changed and when.

What that costs. Additive loading means a second LOAD adds to what you have rather than replacing it, which is what makes two schemas side by side possible -- and it means a careless load lands tables you did not expect. The scoped forms exist for exactly that: CLOSE and SAVE act on one workspace by default, with an explicit form for everywhere.

Why it was not simply switched on. Co-residency was never a memory problem; it is a naming problem. Four hazards were named here before any code was committed to them, and they are worth keeping visible because three have since closed:

• Relation scope. Closed 2026-08-23. The relation store is partitioned by workspace, so a refresh knows whose graph it belongs to. A follow-on hole -- the refresh parent still resolving unscoped -- closed 08-27.
• Work-area budget. Closed. Allocation is workspace-aware. Measured: one workspace took areas 0-1, a second took the lowest free slot and grew contiguously from there.
• Name resolution. Half closed. Within one workspace two areas can no longer share a logical name: USE refuses an explicit alias already held, and auto-renames a stem collision to <stem>2 and says so. The two resolvers that used to disagree are now built on one primitive. Still open: CREATE will open a second same-named table without renaming, and SELECT <name> is not workspace-scoped. This remains the sharp one.
• RAM residency. Still open. Hydration flattens tables to filenames under one virtual root, so two hydrated workspaces would both want the same STUDENTS.dbf slot. A per-workspace subroot is still a decision, not a feature.

A fifth hazard was not on the original list and turned out to matter as much as any of them:

• Environment ownership. Closed 2026-08-29. The DBF, INDEXES and LMDB path slots used to be global, and switching workspaces moved membership without moving them -- so with two systems open, a table in one would resolve its index container under the other. The slots are now stamped on the workspace and restored on switch, with SET PATH <slot> <value> IN <ws> to bind another workspace by name.

What sharing means. The RAM virtual disk is in-process. Another user, or another process, cannot see your hydrated workspace at all -- so sharing is necessarily an explicit act: write it back to disk, or send it. That is a constraint, but a clarifying one, because it puts locking exactly where it belongs -- at the moment work crosses back into shared storage, not around the private work itself.

Nesting

A MINIDB is the portable database image: workspace posture plus member files in one memo payload. Hydration produces a live workspace.

Nesting needed explicit depth, cycle, ownership, resolution and close-order rules before it could be published. Four of those five now have answers:

• Ownership. WORKSPACE NEW <name> UNDER <parent> records the parent's durable catalog id, never the session handle -- a handle does not survive the process, and the durable id is what persistence means.
• Depth. Recorded as the parent's depth plus one, computed when the row is written rather than asserted afterwards.
• Cycle. Refused at creation, alongside a refusal for a parent that does not exist.
• Close order. WORKSPACE DESTROY retires only an empty, childless workspace. A setting decides whether closing a workspace descends into nested ones, and a skipped child is always reported rather than silently left behind.
• Resolution is the one still genuinely open -- see the name-resolution hazard above.

The governing rule is that containment is declared, never inferred. A workspace with no recorded parent means exactly one thing: no container was declared. A workspace whose intended parent has no durable identity is refused at declaration rather than quietly recorded as a root -- because an intent expressed as an absence cannot be told apart from a default.

One consequence reads as a limitation and is really the rule working: you cannot currently nest under the default workspace, not because of any rule about it, but because it has no durable catalog row, and a container that cannot be named cannot be recorded. Give it one and nesting under it follows with no change to the rules.

Nested MINIDB is a different claim and is not made here. Workspace nesting is declared and durable; a container whose payload holds another container remains chartered and unexercised, with measured at-rest depth of one.

Evidence

Related: Proven capabilities · Schemas (the table of databases) · Regression and proof testing