Dotabase Workspaces

Description

Dotabase Workspaces are configurable databases of typed rows, each with its own schema, human-ID prefix, settings, views, behaviors, and tenant boundary.

Creation establishes the container and its schema before row operations begin. The Dotabase service owns schema and settings mutations, while the row service owns records, identities, queries, and lifecycle effects. Both operate on company-scoped inputs and the database schema stores the durable definitions, so callers use one domain contract instead of manipulating JSON and counters directly.

User Story

As a workspace owner, I create a Dotabase for a new business domain and immediately add structured rows without designing raw SQL tables. I choose a name, human-ID prefix, and initial typed properties, then create records through the same service used by product surfaces and integrations. I can add views and bindings without migrating a bespoke table. I walk away with a durable, searchable workspace whose structure remains visible and governable.

Extension Surface

Configurable: owners choose the schema, settings, views, and behavior bindings, while the storage model and service invariants remain platform-owned.

packages/dotabases/src/services/dotabase-service.ts is the configuration boundary for schemas, settings, and container lifecycle. Customers compose supported types and options; the tenant keys, identity rules, and table relationships are fixed platform invariants.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: Supports create, update, move, archive, restore, and row operations. It is not a general-purpose arbitrary SQL database. Workspaces support typed schemas, stable human IDs, saved views, behavior bindings, row lifecycle operations, and tenant-scoped storage. They do not expose arbitrary joins, user-defined SQL, or independent table migrations. Schema changes must use supported property definitions, and cross-Dotabase computation belongs to explicit relation, derivation, or rollup features.

Implementation Map

• packages/dotabases/src/services/dotabase-service.ts
• packages/dotabases/src/services/dotabase-row-service.ts
• packages/db/src/schema/dotabases.ts

Related Features

Contains Typed Property System and Saved Dotabase Views; underpins every other Dotabase capability.

Operationally, these relationships preserve a clear ownership boundary around Dotabase Workspaces. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/services/dotabase-service.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.