Configuration & limits

Default options

db, err := zeedb.Open("./data", zeedb.Options{})

Zero fields select defaults. Negative or inconsistent limits are rejected. Resource limits apply to a single database directory.

Option	Default	Accounting
`Durability`	`Durable`	Sync before acknowledging commits
`MaxDataBytes`	256 MiB	Live collection/key/value bytes + 64 bytes per record
`MaxMemtableBytes`	4 MiB	Memtable records/tombstones under that accounting
`MaxWALBytes`	16 MiB	WAL threshold that triggers a synchronous checkpoint
`MaxBatchBytes`	1 MiB	Encoded batch payload
`MaxBatchOperations`	4096	Mutations in one atomic batch
`MaxKeyBytes`	4096	Bytes per key
`MaxValueBytes`	1 MiB − 8192	Bytes per value, subject to batch size too
`MaxScanRecords`	1000	Maximum records in one scan
`MaxScanBytes`	8 MiB	Returned records under the accounting model

One MiB is 1 << 20 bytes. Collection names independently contain 1–255 bytes and no NUL.

Coordinate buffer budgets

db, err := zeedb.Open("./data", zeedb.Options{
    Durability:       zeedb.Durable,
    MaxMemtableBytes: 8 << 20,
    MaxWALBytes:      32 << 20,
    MaxScanRecords:   500,
})

MaxBatchBytes must be at least 32 bytes and no greater than the 64 MiB frame-format cap. MaxMemtableBytes must be at least MaxBatchBytes. The WAL budget must fit the memtable budget, one encoded batch, and framing allowance:

MaxWALBytes >= MaxMemtableBytes + MaxBatchBytes + 16

The limits bound different things. A large permitted value can still fail because the encoded batch containing it exceeds its own budget.

Budgets versus memory usage

The counters are not exact heap/RSS or filesystem quotas. Go maps, index strings, sorted key lists, batch copies/encoding, allocation overhead, and concurrent caller-owned results consume additional memory.

The complete SSTable key index and Bloom filter live in memory; values stay on disk. Startup verifies every table block. During recovery, the memtable may temporarily grow to the bounded WAL’s contents before checkpointing.

Disk headroom

Checkpointing writes a new table before reclaiming the old one. Allow space for roughly two live tables, the bounded WAL, metadata, and encoding overhead. Temporary files from interrupted checkpointing are reclaimed after successful recovery.

This is a small-engine resource model, not a hard filesystem quota system. Disk-full failures can leave a write result indeterminate; reopen and reconcile before retrying.

Reopening with different limits

Persisted data must fit the options used to open it. Lower key, value, data, or WAL budgets may prevent reopening. Use the original limits to access data before planning a migration; there is no automatic migration tool.

On scan byte-budget overflow, reduce Limit and retry. See error handling for other failure paths.