Planned · not implemented
Model once, keep structure
The design uses Serializer schemas, generated models and descriptors as a shared foundation for application data, validation and typed commands.
Sarvalekha / Developer tools & services
Sarvalekha Database
In designA 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.
Design phase — not released. No supported release or subscription is established.
Planned capabilities
What is being designed.
Planned · not implemented
Keep acceptance coherent
Planned transactions prepare and validate a document revision before publication. Document-scoped ACID and durability still require implementation and qualification.
Planned · not implemented
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 · not implemented
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.
Know the boundaries
Scope matters.
- 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.
A place in the wider picture
Connected, with clear roles.
What comes next
Direction, without a deadline.
- Schema-defined documents and document-scoped acceptance
- Typed queries, declared indexes and bounded caching
- Qualified persistence, recovery and policy-controlled hosted access