amoradbx 2.0.0

package/CHANGELOG.md

@@ -0,0 +1,43 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [2.0.0] - 2026-04-03
+
+### Added
+- **Multi-threading support**: Added `WorkerPool` and `SharedArrayBuffer` support for parallel operations (up to 8 threads).
+- **SIMD acceleration**: Integrated `wasm_simd128` for faster group probing in Swiss Tables and bulk memory operations.
+- **Swiss Table design**: Replaced standard hash map with a high-performance Swiss Table implementation for better cache locality and probing efficiency.
+- **Bloom Filters**: Added 256KB Bloom Filters per shard (64 shards total) to minimize expensive lookups for non-existent keys.
+- **Skip List index**: Implemented a 16-level sorted index for efficient prefix and range scans.
+- **Write-Ahead Log (WAL)**: Added durability via an append-only WAL with CRC32C integrity checks and automatic recovery.
+- **Slab Allocator**: Custom 32-class slab allocator to reduce memory fragmentation and allocation overhead.
+- **Atomic Batches**: Support for ACID-like batch writes with rollback on failure.
+- **Buffered Writes**: Added command buffer (512KB) for high-throughput asynchronous writes.
+- **Snapshot Export/Import**: Full database snapshots with per-record CRC32C checksums.
+- **RapidHash**: Switched to RapidHash for improved hash distribution and performance.
+- **Real-world Benchmark**: Introduced `benchmark.js` for accurate performance profiling including JS bridge overhead and latency percentiles (P50/P99).
+- **npm package**: Added `package.json` for publishing as `amoradbx`.
+
+### Changed
+- **Increased Limits**: Maximum value size increased to 1MB (16x previous limit).
+- **Key Optimization**: Added 22-byte inline fast path for small keys to eliminate heap allocation.
+- **Memory Management**: Optimized memory growth and boundary checks for large datasets.
+
+### Fixed
+- **Windows WAL fix**: Optimized file-writing strategy in `amora.js` to prevent `EPERM` errors during WAL updates on Windows.
+- Improved race condition handling in multi-threaded environments using `_Atomic` types and explicit memory ordering.
+- Enhanced CRC32C performance with a slice-by-4 unrolled implementation.
+
+## [1.0.0] - 2026-04-02
+
+### Added
+- Initial release of AmoraDB.
+- Core key-value engine in C and WebAssembly.
+- Basic Node.js bindings.
+- Support for `set`, `get`, `has`, and `delete` operations.
+- Simple in-memory storage.
+- Basic benchmarking harness.

package/CONTRIBUTING.md

@@ -0,0 +1,77 @@
+# Contributing to AmoraDB
+
+Thank you for your interest in contributing to AmoraDB! We're excited to have you join our community.
+
+## Code of Conduct
+
+Please follow our Code of Conduct in all your interactions with the project.
+
+## How to Contribute
+
+1.  **Report Bugs**: If you find a bug, please open an issue with a clear description and steps to reproduce.
+2.  **Suggest Features**: Have an idea for a new feature? Open an issue to discuss it.
+3.  **Submit Pull Requests**:
+    *   Fork the repository.
+    *   Create a new branch for your changes.
+    *   Implement your changes and add tests.
+    *   Ensure all tests pass (`node test.js`).
+    *   Submit a pull request.
+
+## Development Environment Setup
+
+### Prerequisites
+
+*   **Node.js**: Version 18 or higher.
+*   **Emscripten** or **wasi-sdk**: To compile the C core to WebAssembly.
+
+### Building from Source
+
+To build the `amora_core_mt_simd.wasm` binary with full multi-threading and SIMD support:
+
+```bash
+clang --target=wasm32 -O3 -nostdlib -std=c11 \
+  -msimd128 -matomics -mbulk-memory \
+  -fvisibility=hidden -ffunction-sections -fdata-sections \
+  -Wl,--no-entry -Wl,--export-dynamic \
+  -Wl,--import-memory -Wl,--shared-memory \
+  -Wl,--max-memory=4294967296 \
+  -Wl,--gc-sections -Wl,--allow-undefined -Wl,--lto-O3 \
+  -flto -DCACHE_LINE=256 \
+  -o amora_core_mt_simd.wasm amora_core.c
+```
+
+### Running Tests
+
+Run the full test suite using Node.js:
+
+```bash
+node test.js
+```
+
+The test suite covers performance benchmarks, stress tests, and core functionality checks.
+
+## Coding Standards
+
+### C Core (`amora_core.c`)
+
+*   Standard C11.
+*   No standard library dependencies (`-nostdlib`).
+*   Use `u8`, `u16`, `u32`, `u64` for fixed-width integers.
+*   Optimize for performance: use `INLINE` for small functions and minimize allocations.
+*   Maintain thread safety using `_Atomic` types and memory ordering where necessary.
+
+### Node.js Binding (`amora.js`)
+
+*   Follow standard Node.js practices.
+*   Ensure backward compatibility with older Node.js versions if possible (minimum v18).
+*   Maintain the high-performance philosophy: avoid unnecessary copying and allocations.
+*   Use `SharedArrayBuffer` for multi-threaded communication.
+
+## Documentation
+
+*   Update the `README.md` and `SPEC.md` for any major architectural changes or new features.
+*   Keep comments clear and concise.
+
+## Licensing
+
+By contributing to AmoraDB, you agree that your contributions will be licensed under the MIT License.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Amoracoin
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,360 @@
+<div align="center">
+
+<img src="https://github.com/amoracoin-org/AmoraDb/blob/main/assets/amoradb-logo.jpeg" alt="AmoraDB" width="180"/>
+
+# AmoraDB
+
+**Ultra-High-Performance Embedded Key-Value Engine**
+
+*Built in C · Compiled to WebAssembly · Bound to Node.js*
+
+[![License: MIT](https://img.shields.io/badge/License-MIT-blueviolet.svg)](#license)
+[![WebAssembly](https://img.shields.io/badge/WebAssembly-SIMD128-654ff0?logo=webassembly)](https://webassembly.org/)
+[![Node.js](https://img.shields.io/badge/Node.js-Binding-339933?logo=nodedotjs)](https://nodejs.org/)
+[![Version](https://img.shields.io/badge/version-2.0-ff69b4)](#)
+
+</div>
+
+---
+
+### 📖 Documentation
+
+- **[CHANGELOG.md](CHANGELOG.md)**: Track all notable changes and version history.
+- **[CONTRIBUTING.md](CONTRIBUTING.md)**: Guide for setting up development environment and contributing code.
+- **[SPEC.md](SPEC.md)**: Deep dive into the internal architecture, sharding, and binary formats.
+
+---
+
+AmoraDB is a hand-crafted, zero-dependency key-value store written entirely in C and compiled to WebAssembly. It is designed for scenarios where you need **millions of operations per second**, atomic batch writes, WAL-backed durability, and a minimal footprint — all inside a Node.js process with no native addons.
+
+It outperforms LevelDB and competes with LMDB at in-memory workloads, with the portability advantage of running anywhere WebAssembly runs.
+
+---
+
+## ✨ Features
+
+| Capability | Detail |
+|---|---|
+| **Hash Map** | Swiss Table design with SIMD-accelerated group probing (`wasm_simd128`) |
+| **Sharding** | 64 independent shards for lock-free parallelism |
+| **Bloom Filters** | 256 KB per shard (2M bits) for zero-cost negative lookups |
+| **Skip List** | 16-level sorted index, supports billions of entries |
+| **WAL** | Append-only Write-Ahead Log with CRC32C integrity, up to 32 MB |
+| **Snapshots** | Full export/import with per-record CRC32C checksums |
+| **Atomic Batches** | ACID-like batch writes with rollback on failure |
+| **Worker Threads** | Shared `SharedArrayBuffer` memory across up to 8 threads |
+| **Slab Allocator** | 32 size classes, `SLAB_MIN_SIZE` 16B → `SLAB_MAX_SIZE` per class |
+| **GC / Compaction** | Tombstone-aware compaction with auto-compact threshold |
+| **Large Values** | Up to 1 MB per value (16× previous limit) |
+| **Large Keys** | Up to 4 KB per key, with 22-byte inline fast path |
+
+---
+
+## 📊 Performance
+
+Benchmarks run with the built-in `db.bench(1_000_000)` harness (C-level, 1M operations, in-memory):
+
+| Operation | Throughput |
+|---|---|
+| Write | ~1.5M+ ops/s |
+| Read | ~1.7M+ ops/s |
+| Delete | ~1.7M+ ops/s |
+
+### Comparison (in-memory, single node)
+
+| Engine | Write/s | Read/s | Notes |
+|---|---|---|---|
+| **AmoraDB v2.0** | ~1.5M+ | ~1.7M+ | WASM · SIMD · 64 shards |
+| LMDB | ~1.2M | ~2.0M | mmap · B+Tree · C addon |
+| RocksDB | ~700K | ~900K | LSM · disk-tuned · C addon |
+| LevelDB | ~400K | ~600K | LSM · disk · C addon |
+| Redis (local) | ~500K | ~800K | TCP overhead · RAM |
+
+### Internal benchmark 1,000,000 ops (pure C)
+
+The internal benchmark measures raw performance at the C level, bypassing the Node.js bridge.
+
+### Real-World Benchmark (Node.js)
+
+For a more accurate measure of performance including JavaScript overhead and real-world latency, run:
+
+```bash
+node benchmark.js
+```
+
+This benchmark covers:
+- **JS <-> WASM Bridge**: Real overhead of calling the engine from Node.js.
+- **Latency (P50/P99)**: Tracks sub-millisecond response times.
+- **Concurrency**: Parallel execution across worker threads.
+- **Persistence**: Impact of WAL durability (Async vs Sync).
+
+> Benchmarks are illustrative. Results vary by hardware, key size, value size, and access pattern.
+>
+> ⚠️ Note: LevelDB and RocksDB are disk-first engines optimized for persistence and compaction. Redis includes TCP overhead. This comparison reflects raw in-process throughput only — not overall capability. Choose the right tool for your use case.
+---
+
+## 🏗 Architecture
+
+```
+┌─────────────────────────────────────────────────┐
+│                   amora.js                      │  Node.js Binding
+│  LRU string cache · encodeInto · SharedArrayBuf │
+│  Command buffer (512KB) · Worker pool (8 max)   │
+└────────────────────┬────────────────────────────┘
+                     │  WebAssembly
+┌────────────────────▼────────────────────────────┐
+│                amora_core.c → .wasm             │  Core Engine
+│                                                 │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
+│  │ Shard 0  │  │ Shard 1  │  │  ...63   │      │  64 Shards
+│  │ SwissMap │  │ SwissMap │  │ SwissMap │      │
+│  │ Bloom    │  │ Bloom    │  │ Bloom    │      │  256KB Bloom/shard
+│  └──────────┘  └──────────┘  └──────────┘      │
+│                                                 │
+│  ┌──────────────────────────────────────────┐   │
+│  │         Skip List  (16 levels)           │   │  Sorted index
+│  └──────────────────────────────────────────┘   │
+│                                                 │
+│  ┌──────────────────────────────────────────┐   │
+│  │    WAL  (CRC32C · 32MB · append-only)    │   │  Durability
+│  └──────────────────────────────────────────┘   │
+└─────────────────────────────────────────────────┘
+```
+
+**Hash function:** [RapidHash](https://github.com/Nicoshev/rapidhash) — excellent distribution, minimal collisions.
+
+**Integrity:** CRC32C with a 256-entry lookup table, processed 4 bytes per iteration (slice-by-4 unroll).
+
+**Atomics:** When compiled with `__wasm_threads__`, all shard counters use `_Atomic` types with explicit memory ordering (acquire/release/relaxed).
+
+---
+
+## 🚀 Getting Started
+
+### Prerequisites
+
+- Node.js ≥ 18
+- Bundled WebAssembly binary (`amora_core_mt_simd.wasm`) when installed from npm (or build from source — see below)
+
+### Installation
+
+```bash
+npm install amoradbx
+```
+
+### Basic Usage
+
+```js
+const AmoraDB = require('amoradbx');
+
+// Open a database (in-memory + optional WAL persistence)
+const db = AmoraDB.open(null, {
+  threads:  4,
+  cap:      65536,      // Initial capacity (entries)
+  walPath:  './my.wal', // Omit for pure in-memory
+  walSync:  true,       // fsync on every WAL flush
+});
+
+// Basic operations
+db.set('user:1', 'alice');
+db.get('user:1');         // → 'alice'
+db.has('user:1');         // → true
+db.delete('user:1');
+
+// Multi-get
+const results = db.mget(['user:1', 'user:2', 'missing']);
+// → ['alice', 'bob', null]
+
+// Prefix scan
+const entries = db.scan('user:');
+// → [{ key: 'user:1', value: 'alice' }, ...]
+
+// Range scan
+const range = db.range('user:1', 'user:9');
+```
+
+### Atomic Batch Writes
+
+```js
+db.batch([
+  { op: 'set',    key: 'account:1', value: '500' },
+  { op: 'set',    key: 'account:2', value: '300' },
+  { op: 'delete', key: 'account:old' },
+]);
+// All succeed or all roll back — no partial writes.
+```
+
+### Buffered Writes (High Throughput)
+
+```js
+// setBuffered queues writes in a 512KB command buffer
+for (let i = 0; i < 100_000; i++) {
+  db.setBuffered(`key:${i}`, `value:${i}`);
+}
+db.flush(); // Commit all at once
+```
+
+### Snapshot Export / Import
+
+```js
+// Export entire database to a Buffer
+const snapshot = db.export(128 * 1024 * 1024); // 128MB max
+
+// Import into a fresh instance
+const db2 = AmoraDB.open(null, { cap: 65536 });
+const count = db2.import(snapshot);
+console.log(`Imported ${count} entries`);
+```
+
+---
+
+## ⚙️ Configuration Options
+
+| Option | Type | Default | Description |
+|---|---|---|---|
+| `threads` | `number` | `1` | Number of worker threads (max 8) |
+| `cap` | `number` | `65536` | Initial hash map capacity per shard |
+| `walPath` | `string\|null` | `null` | Path for WAL file. `null` = no persistence |
+| `walSync` | `boolean` | `true` | `fsync` after every WAL flush |
+
+---
+
+## 🔧 API Reference
+
+### Core Operations
+
+| Method | Returns | Description |
+|---|---|---|
+| `db.heartbeat()` | `boolean` | Check if WASM core is responsive |
+| `db.set(key, value)` | `void` | Insert or update a key |
+| `db.get(key)` | `string\|null` | Retrieve a value |
+| `db.has(key)` | `boolean` | Check existence (uses bloom filter) |
+| `db.delete(key)` | `void` | Remove a key |
+| `db.setBuffered(key, value)` | `void` | Buffered write (flush manually) |
+| `db.mget(keys[])` | `(string\|null)[]` | Batch get (up to 8192 keys) |
+| `db.batch(ops[])` | `void` | Atomic multi-operation batch |
+| `db.scan(prefix)` | `{key,value}[]` | All keys with given prefix |
+| `db.range(from, to)` | `{key,value}[]` | Lexicographic range scan |
+
+### Maintenance
+
+| Method | Returns | Description |
+|---|---|---|
+| `db.gc()` | `number` | Compact tombstones across all shards |
+| `db.autoCompact()` | `number` | GC if fragmentation > 25% |
+| `db.fragmentation()` | `number` | Current fragmentation percentage |
+| `db.flush()` | `void` | Flush pending command buffer |
+| `db.persist()` | `void` | Flush + WAL write |
+| `db.restore()` | `void` | Reload from WAL |
+| `db.reset(cap?)` | `void` | Wipe and reinitialize |
+| `db.close()` | `Promise<void>` | Async: flush, persist, terminate workers |
+| `db.import(buf)` | `number` | Import snapshot buffer |
+| `db.export(max?)` | `Buffer` | Export database to snapshot buffer |
+
+### Observability
+
+```js
+const s = db.stats();
+// {
+//   count:          number,   // Live entries
+//   capacity:       number,   // Allocated slots
+//   deleted:        number,   // Tombstone count
+//   shards:         64,
+//   threads:        number,
+//   load:           '73.2%',
+//   fragmentation:  '12%',
+//   hit_rate:       '98.7%',
+//   total_ops:      number,
+//   write_errors:   number,
+//   wal_errors:     number,
+//   compactions:    number,
+//   arena_kb:       string,
+//   wal_kb:         string,
+//   wasm_mb:        string,
+//   mem_shared:     boolean,
+// }
+```
+
+### Benchmark
+
+```js
+const b = db.bench(1_000_000);
+// {
+//   ops:          1000000,
+//   write_ms:     '312ms',   write_ops_s:  '3.20M',
+//   read_ms:      '276ms',   read_ops_s:   '3.62M',
+//   delete_ms:    '289ms',   delete_ops_s: '1.73M',
+//   scan_ms:      '1.42ms',
+// }
+```
+
+---
+
+## 🔒 Limits & Safety
+
+| Constraint | Limit |
+|---|---|
+| Maximum key size | 4,096 bytes |
+| Maximum value size | 1,048,576 bytes (1 MB) |
+| Inline key fast path | ≤ 22 bytes (zero heap allocation) |
+| Shards | 64 |
+| Worker threads | 8 |
+| Scan results per call | 4,096 |
+| WAL max size | 32 MB |
+
+All limits are validated on the JavaScript side before reaching WASM. Violations throw a `RangeError` immediately.
+
+---
+
+## 🛠 Building from Source
+
+AmoraDB core is written in standard C99 with optional SIMD and atomics extensions for WebAssembly. Build with [Emscripten](https://emscripten.org/) or [wasi-sdk](https://github.com/WebAssembly/wasi-sdk):
+
+```bash
+clang --target=wasm32 -O3 -nostdlib -std=c11 \
+  -msimd128 -matomics -mbulk-memory \
+  -fvisibility=hidden -ffunction-sections -fdata-sections \
+  -Wl,--no-entry -Wl,--export-dynamic \
+  -Wl,--import-memory -Wl,--shared-memory \
+  -Wl,--max-memory=4294967296 \
+  -Wl,--gc-sections -Wl,--allow-undefined -Wl,--lto-O3 \
+  -flto -DCACHE_LINE=256 \
+  -o amora_core_mt_simd.wasm amora_core.c
+```
+
+> The `-msimd128`, `-matomics`, and `-mbulk-memory` flags enable full multi-threaded SIMD mode. Remove them to build a single-threaded fallback.
+
+---
+
+## 📁 Project Structure
+
+```
+amora/
+├── amora_core.c      # Core engine — hash map, WAL, bloom, skip list, slab
+├── amora_core_mt_simd.wasm   # Compiled WebAssembly binary — multi-threaded, SIMD acceleration
+├── amora.js          # Node.js binding — workers, caching, serialization
+└── test.js          # Full test suite with stress and benchmarks
+```
+
+---
+
+## 🧪 Running Tests
+
+```bash
+node test.js
+```
+
+The test suite covers: heartbeat, set/get/has/delete, large values (512 KB), key/value size validation, update / 1000 rewrites, mget, atomic batch, batch rollback (single and repeated), prefix scan, fragmentation + GC, snapshot export/import with CRC corruption detection, stats, stress (100K keys), and the internal 1M-op C benchmark.
+
+---
+
+## 📄 License
+
+MIT © AmoraDB Authors
+
+---
+
+<div align="center">
+  <sub>Built with obsession for performance. No dependencies. No compromises.</sub>
+</div>
+

package/SPEC.md

@@ -0,0 +1,85 @@
+# AmoraDB Technical Specification
+
+AmoraDB is an ultra-high-performance, zero-dependency, sharded key-value storage engine built in C and compiled to WebAssembly for Node.js environments.
+
+## 1. Core Architecture
+
+### 1.1 Sharding Strategy
+- **Shards**: 64 independent shards (`N_SHARDS = 64`).
+- **Parallelism**: Shard-level locking using atomic spinlocks for multi-threaded operations.
+- **Distribution**: Keys are hashed using `RapidHash`, and the top 6 bits determine the shard index.
+
+### 1.2 Hash Table (Swiss Table)
+- **Design**: Google's Swiss Table inspired design for high cache locality and SIMD probing.
+- **Group Size**: 16 slots per group (`GROUP_SIZE = 16`).
+- **Control Bytes**: Each slot has a 1-byte control value (Empty `0x80`, Deleted `0xFE`, or 7-bit hash suffix).
+- **Probing**: Linear probing with `wasm_simd128` group filtering.
+
+### 1.3 Bloom Filters
+- **Memory**: 256 KB per shard (2M bits total per shard).
+- **Functions**: 6 hash functions per lookup.
+- **Effectiveness**: Near-zero cost for negative lookups (non-existent keys).
+
+### 1.4 Sorted Index (Skip List)
+- **Levels**: 16-level probabilistic Skip List.
+- **Capacity**: Supports up to 1M nodes.
+- **Operations**: Prefix scans and lexicographic range queries.
+
+### 1.5 Memory Management
+- **Slab Allocator**: Custom 20-class slab allocator for key/value storage.
+- **Classes**: 16B to 1MB size classes.
+- **GC/Compaction**: Tombstone-aware garbage collection with a 25% fragmentation threshold.
+- **Inline Keys**: Keys ≤ 22 bytes are stored directly within the hash table slot to avoid extra allocations.
+
+## 2. Durability & Integrity
+
+### 2.1 Write-Ahead Log (WAL)
+- **Format**: Append-only log with CRC32C checksums for every record.
+- **Header**: 8-byte header (`WAL_MAGIC = 0x414D5257`, `WAL_VERSION = 20`).
+- **Size Limit**: 32 MB per WAL file.
+- **Recovery**: Automatic replay on database open with error reporting for corrupted entries.
+
+### 2.2 Data Integrity
+- **Checksums**: Slice-by-4 CRC32C unrolled implementation for high-speed verification.
+- **Snapshots**: Full database exports include per-record CRC32C checksums to detect data corruption.
+
+## 3. Concurrency & Performance
+
+### 3.1 Multi-threading
+- **Workers**: Up to 8 worker threads using Node.js `worker_threads`.
+- **Memory**: Shared `SharedArrayBuffer` memory between main thread and workers.
+- **Synchronization**: `stdatomic.h` with `acquire/release/relaxed` memory ordering for lock-free counters and spinlocks.
+
+### 3.2 Performance Targets
+- **Writes**: 1.5M+ ops/s (in-memory, single node).
+- **Reads**: 1.7M+ ops/s (in-memory, single node).
+- **Latency**: Sub-microsecond access times for small key/value pairs.
+
+## 4. API Specification
+
+### 4.1 Core Methods
+- `set(key, value)`: Atomic insertion or update.
+- `get(key)`: Fast retrieval with Bloom filter bypass for negative hits.
+- `has(key)`: Bloom filter check.
+- `delete(key)`: Logical deletion with tombstone marking.
+- `batch(ops[])`: ACID-like atomic batch operations with rollback capability.
+
+### 4.2 Scanning
+- `scan(prefix)`: Prefix-based range scan.
+- `range(from, to)`: Inclusive lexicographic range scan.
+
+## 5. Limits & Constraints
+
+- **Maximum Key Size**: 4,096 bytes (4 KB).
+- **Maximum Value Size**: 1,048,576 bytes (1 MB).
+- **Inline Key Fast Path**: ≤ 22 bytes.
+- **Max Threads**: 8.
+- **Max WAL Size**: 32 MB.
+- **Max Shards**: 64.
+- **Max Memory**: Up to 4GB (WASM limit).
+
+## 6. Binary Format (WAL/Snapshots)
+
+- **WAL Record**: `[Type:1][KLen:2][VLen:4][Key:KLen][Value:VLen][CRC:4]`
+- **Snapshot Header**: `[Magic:4][Version:4][Count:4][Reserved:20]`
+- **Snapshot Record**: `[KLen:2][VLen:4][Key:KLen][Value:VLen][CRC:4]`