Planned design
Model once, keep structure
The design uses Serializer schemas, generated models and descriptors as a shared foundation for application data, validation and typed commands.
Public product notes
Database, in context.
A schema-driven structured document database for connected application data.
Purpose & status.
A document can hold more than a file. Database is being designed around schema-defined objects, stable identities and deliberate relationships, with one document as the initial transaction boundary.
Capability scope.
Planned design
Keep acceptance coherent
Planned transactions prepare and validate a document revision before publication. Document-scoped ACID and durability still require implementation and qualification.
Planned design
Make resource choices explicit
Planned memory and disk cache providers use shared budgets and source/access validity rules. Actual memory, storage and performance limits remain to be measured.
Planned design
Connect local and managed workflows
Embedded C++ access and a shared typed hosted command model are design targets. Remote transports, managed hosting and supported deployment profiles are not released.
Important limitations.
- Design phase — not released. Design ready is a planning milestone, not a downloadable or hosted database.
- The initial transaction boundary is one document. Cross-document ACID, general SQL, unrestricted joins and automatic sharding are outside the initial profile.
- References, coordinates or vectors do not establish graph, geospatial or vector query engines. Replication, recovery and compliance-support profiles require independent qualification.