Available today
The experimental storage MVP provides embedded collection/key/value operations, atomic single-shard batches, consistent per-call reads/scans, a checksummed WAL, SSTables, synchronous compaction, recovery, budgets, a CLI, and local test/benchmark tooling.
The standalone HTTP server adds language-independent access, full-access bearer authentication, optional TLS, bounded requests, and Docker packaging. JavaScript and Python integration examples use the same API locally and remotely.
The API and on-disk format may evolve. Current status is not a production-readiness claim or a stable release guarantee.
Planned work
| Stage | Intended scope |
|---|---|
| Storage hardening | Broader fault injection, sustained stress, backups, migration tooling |
| Server hardening | Tenant authorization, per-user quotas, audited security, operational validation |
| SyncPath | Atomic outbound journal, stable operation IDs, idempotent push, durable pull cursors, tombstones, conflict status |
| Query acceleration | Secondary indexes, persistent snapshots, measured FastPath specialization |
| Platform adapters | Browser/mobile persistence adapters and SDKs |
These are design directions, not currently callable APIs or committed delivery dates.
SyncPath is a proposal
The planned protocol uses stable operation IDs and base versions to make retries explicit and detect stale writes. The design calls for atomically committing record changes with journal/feed entries and cursor advances.
The intended default conflict policy is server-authoritative optimistic concurrency, with conflicts surfaced for resolution. The current engine does not implement a sync journal, push/pull endpoints, per-record remote authorization, or automatic merging.
FastPath is a proposal
FastPath is intended to specialize common validated operations and cache execution/index/encoding choices. No PrepareFastPath method, SQL parser, secondary-index API, or runtime code generation exists in the storage MVP.
Explicit non-goals for early releases
- Full SQL or PostgreSQL compatibility.
- Distributed consensus or multi-region active-active replication.
- Automatic merging of arbitrary offline document conflicts.
- Browser-native execution of the Go storage engine.
- Unvalidated claims of superiority over established databases.
See the original system blueprint for architectural context and acceptance gates. Its timelines and performance targets remain proposals.