Limitations - NetlyDB documentation

Data model and scale

Collections are held in memory. Data sets larger than memory are not supported, and startup time grows with data size.
One database per process; one writable owner per store.
No supported performance or scale envelope is stated. Performance gives measurements on one machine, not guarantees, and no maximum scale. A single sequential writer pays one disk flush per write; use batch inserts for bulk loads.
Taking a snapshot briefly holds writes to that collection (a few milliseconds at the measured sizes since 1.2.0).
Range queries over a sorted index iterate linearly. The query planner has no cost model.
Queries without an explicit order have no guaranteed order.

No transactions across collections. Batches are recoverable but not atomically visible.
No point-in-time recovery; snapshots and backups are per collection.
Each collection's WAL is one file, compacted when a snapshot is published.
Corruption in the middle of a WAL requires manual, offline intervention.
Downgrade is not supported; rolling back means restoring a backup. There is no rolling upgrade across versions.
Recovery reports what it refuses; it does not repair it. A store refused for an unusable snapshot, or recorded as holding a collection it had dropped, needs an operator's decision, as the failure describes.

HNSW recall is labelled but not yet measured. The HNSW graph is rebuilt on load.
Externally set vectors are durable from the next snapshot and are not replicated.
No filtering inside vector search, no hybrid ranking, one English full-text analyzer.
Managed embedding generation is not in a published package.

Cross-machine clustering needs 1.1.0 or later. Mixing NetlyDB versions in one cluster is not a tested configuration: upgrade every node together.
Last-write-wins: concurrent updates to one document on different nodes lose one value. No quorum writes, no automatic failover, no consensus membership, no linearizable reads.
File-collection conflicts resolve on wall-clock time. A local truncate is not replicated.

Supported: Linux x64, Windows x64, macOS arm64, on .NET 10. Android arm64 compiles but has not been run. .NET MAUI, iOS and Blazor WebAssembly are not supported; browser support is in development, planned for 1.3 (see Browser & WebAssembly).
The Azure Blob storage provider is read-only.
File collections record where each file's content is stored as an absolute path. A store restored from a backup or moved to another directory opens and recovers, but its file contents may not be readable there; restore such a store to its original location.
Management UI image previews and thumbnails work on Windows (x86, x64) and Linux x64 only; elsewhere, including macOS arm64, image files can be downloaded but not previewed.
No remote client: out-of-process access is through the REST API or MCP server.
Packages are not code-signed.

Five declared audit actions are not recorded yet (snapshot quarantine and pruning, index rebuild requests, ownership acquisition and release).
There is no operator-initiated repair command; recovery retry is a process restart.
No telemetry exporter is bundled.
The REST API and MCP server do not yet map an engine-state refusal (for example, a read while recovery is required) to a dedicated response.