|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## What Makes PomaiDB Unique |
| 6 | + |
| 7 | +PomaiDB is designed as a **multimodal embedded database for edge devices** with several distinctive features: |
| 8 | + |
| 9 | +- **True Multimodal Storage**: Unlike traditional vector databases, PomaiDB supports 12+ membrane types (vectors, RAG, graphs, text, time series, key-value, metadata, sketches, spatial data, meshes, sparse vectors, bitsets) allowing storage and querying of diverse data modalities in a single database. |
| 10 | + |
| 11 | +- **Edge-Native Single-Threaded Architecture**: Designed for deterministic latency on constrained hardware with no mutexes, lock-free queues, or race conditions - similar to Redis/Node.js event loop but optimized for flash storage longevity. |
| 12 | + |
| 13 | +- **Zero-OOM Guarantee**: Integrated with palloc for arena-style allocation with hard memory limits, combined with backpressure mechanisms to prevent out-of-memory crashes on edge devices. |
| 14 | + |
| 15 | +- **Offline-First Edge RAG**: Complete retrieval-augmented generation pipeline that runs entirely on-device (ingest → chunk → embed → store → retrieve) without external APIs, featuring zero-copy chunking and pluggable embedding providers. |
| 16 | + |
| 17 | +- **Multimodal Query Orchestration**: Hybrid search across different membrane types (vector + lexical + graph traversal) with heuristic execution ordering and bounded frontier RAM. |
| 18 | + |
| 19 | +- **Flash-Optimized Storage**: Append-only, log-structured design with tombstone-based deletion that minimizes random writes and extends SD/eMMC card lifespan. |
| 20 | + |
| 21 | +- **Built-in Edge Features**: HTTP endpoints, MQTT/WebSocket-style ingestion, hardware wear-aware maintenance, encryption-at-rest, and mini-OLAP analytical aggregates. |
| 22 | + |
| 23 | +## Development Commands |
| 24 | + |
| 25 | +### Build |
| 26 | +```bash |
| 27 | +# Standard release build |
| 28 | +mkdir build && cd build |
| 29 | +cmake .. -DCMAKE_BUILD_TYPE=Release |
| 30 | +make -j$(nproc) |
| 31 | + |
| 32 | +# Build with tests |
| 33 | +cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DPOMAI_BUILD_TESTS=ON |
| 34 | +cmake --build build -j$(nproc) |
| 35 | + |
| 36 | +# Edge-optimized build (smaller binary, less debug) |
| 37 | +cmake .. -DCMAKE_BUILD_TYPE=Release -DPOMAI_EDGE_BUILD=ON |
| 38 | +``` |
| 39 | + |
| 40 | +### Tests |
| 41 | +```bash |
| 42 | +# Run full test suite |
| 43 | +cd build |
| 44 | +ctest --test-dir . --output-on-failure |
| 45 | + |
| 46 | +# Run a single test (replace TestName with actual test name) |
| 47 | +cd build |
| 48 | +ctest -R TestName --output-on-failure |
| 49 | + |
| 50 | +# Run tests with verbose output |
| 51 | +cd build |
| 52 | +ctest --verbose |
| 53 | +``` |
| 54 | + |
| 55 | +### Benchmarks |
| 56 | +```bash |
| 57 | +# Build benchmarks |
| 58 | +cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DPOMAI_BUILD_BENCH=ON |
| 59 | +cmake --build build -j$(nproc) |
| 60 | + |
| 61 | +# Run all benchmarks |
| 62 | +./scripts/run_benchmarks_one_by_one.sh |
| 63 | + |
| 64 | +# Run specific benchmark |
| 65 | +cd build |
| 66 | +ctest -R bench_ --output-on-failure |
| 67 | +``` |
| 68 | + |
| 69 | +### Code Quality |
| 70 | +```bash |
| 71 | +# Check for malloc/new usage (should use palloc) |
| 72 | +./scripts/check_no_malloc_new.sh |
| 73 | + |
| 74 | +# Verify API contract |
| 75 | +./scripts/check_api_contract.sh |
| 76 | +``` |
| 77 | + |
| 78 | +### Quick Start Examples |
| 79 | +See `examples/` directory for language-specific examples: |
| 80 | +- C++: `examples/quickstart_cpp/` |
| 81 | +- C: `examples/quickstart_c/` |
| 82 | +- Python: `examples/quickstart_python/` |
| 83 | +- RAG: `examples/rag_quickstart/` |
| 84 | + |
| 85 | +## Architecture Overview |
| 86 | + |
| 87 | +### What Makes PomaiDB a Multimodal Embedded Database |
| 88 | + |
| 89 | +PomaiDB's architecture is specifically designed to be a **multimodal embedded database for edge devices**, combining several unique capabilities: |
| 90 | + |
| 91 | +- **Unified Multimodal Storage**: Single database engine that handles vectors, text, graphs, time series, spatial data, 3D meshes, and more through its membrane system, enabling true multimodal AI applications on edge devices. |
| 92 | + |
| 93 | +- **Deterministic Edge Performance**: Single-threaded event loop eliminates concurrency complexity while providing predictable latency crucial for real-time edge applications. |
| 94 | + |
| 95 | +- **Flash-Optimized for Longevity**: Append-only, log-structured storage minimizes write amplification on SD/eMMC storage, extending device lifespan. |
| 96 | + |
| 97 | +- **Hardware-Aware Resource Management**: Integration with palloc provides hard memory caps and arena-style allocation, preventing OOM crashes on memory-constrained devices. |
| 98 | + |
| 99 | +- **Complete On-Device AI Pipeline**: Offline-first RAG with zero-copy chunking and pluggable embedding providers enables local AI without cloud dependencies. |
| 100 | + |
| 101 | +### Core Design Principles |
| 102 | +- **Single-threaded event loop**: All operations (ingest, search, freeze, flush) run to completion in order, providing deterministic latency and trivial concurrency reasoning. |
| 103 | +- **Shared-nothing architecture**: One logical thread, one storage engine, one logical database per process. |
| 104 | +- **Zero-OOM philosophy**: Bounded memtable size, backpressure (auto-freeze when over threshold), and optional integration with palloc for arena-style allocation and hard memory caps. |
| 105 | +- **Edge-native storage**: Append-only, log-structured storage with tombstone-based deletion, designed for SD-card and eMMC longevity. |
| 106 | +- **Virtual File System (VFS)**: Storage and environment operations go through abstract `Env` and file interfaces. Default backend is POSIX; an in-memory backend supports tests and non-POSIX targets. |
| 107 | + |
| 108 | +### Key Components |
| 109 | +- **DbImpl**: Main database implementation handling core operations (Put, Get, Search, Flush, Freeze, Close). |
| 110 | +- **MembraneManager**: Manages logical collections (membranes) with separate dimensions, sharding, and indexes. Supported kinds include kVector, kRag, kGraph, kText, kTimeSeries, kKeyValue, kMeta, kSketch, kSpatial, kMesh, kSparse, kBitset. |
| 111 | +- **QueryPlanner/QueryOrchestrator**: Plans and executes hybrid/multimodal searches across membranes with heuristic execution ordering, bounded frontier RAM, and metadata partition hints. |
| 112 | +- **Storage Engine**: Log-structured, append-only storage with sequential flush of in-memory buffer to disk. Uses WAL for crash recovery. |
| 113 | +- **RAG Pipeline**: Zero-copy chunking (`std::string_view`), `EmbeddingProvider` interface, and unified `RagPipeline` with `IngestDocument` and `RetrieveContext` methods. |
| 114 | +- **Memory Management**: Optional palloc (mmap-backed or custom allocator) for O(1) arena-style allocation and hard memory limits. Core and C API can use palloc for control structures and large buffers. |
| 115 | +- **I/O Layer**: Sequential write-behind; zero-copy reads (mmap where available via VFS, or buffered I/O). Designed for SD-card and eMMC longevity first, NVMe-friendly by construction. |
| 116 | + |
| 117 | +### Membrane Types (Multimodal Capabilities) |
| 118 | +Each membrane kind enables specific multimodal capabilities: |
| 119 | +- `kVector`: Vector storage with ANN search (IVF, HNSW) - for embeddings and similarity search |
| 120 | +- `kRag`: Retrieval-Augmented Generation pipeline storage - for document retrieval and context augmentation |
| 121 | +- `kGraph`: Graph storage for relationships and linkages - for knowledge graphs and entity relationships |
| 122 | +- `kText`: Raw text storage - for storing and querying unstructured text |
| 123 | +- `kTimeSeries`: Time-series data storage - for sensor data, metrics, and temporal analysis |
| 124 | +- `kKeyValue`: Simple key-value store - for configuration and metadata storage |
| 125 | +- `kMeta`: Metadata storage - for flexible schema-less data tagging |
| 126 | +- `kSketch`: Probabilistic data structures (HyperLogLog, CountMinSketch) - for approximate counting and frequency estimation |
| 127 | +- `kSpatial`: Geospatial data storage - for location-based services and mapping applications |
| 128 | +- `kMesh`: 3D mesh storage with LOD management - for AR/VR, robotics, and spatial computing |
| 129 | +- `kSparse`: Sparse vector storage - for efficient storage of high-dimensional sparse data |
| 130 | +- `kBitset`: Bitmask operations and filtering - for fast set operations and feature flags |
| 131 | + |
| 132 | +### Important Directories |
| 133 | +- `src/`: Core implementation (C++) |
| 134 | +- `include/`: Public headers |
| 135 | +- `sdk/`: Language bindings (Python, etc.) |
| 136 | +- `tests/`: GoogleTest unit and integration tests |
| 137 | +- `benchmarks/`: Performance benchmarks |
| 138 | +- `scripts/`: Utility scripts for building, testing, and benchmarking |
| 139 | +- `examples/`: Quickstart examples in multiple languages |
| 140 | +- `docs/`: Detailed documentation (edge release, deployment, failure semantics, etc.) |
| 141 | + |
| 142 | +## Common Development Tasks |
| 143 | + |
| 144 | +### Adding a New Membrane Type (Extending Multimodal Capabilities) |
| 145 | +1. Define the membrane kind in `include/pomai/types.h` (add to `MembraneKind` enum) |
| 146 | +2. Implement the membrane class in `src/core/membranes/` (follow existing patterns like `VectorMembrane` or `RagMembrane`) |
| 147 | +3. Register the membrane in `MembraneManager::CreateMembrane()` and `MembraneManager::GetMembrane()` |
| 148 | +4. Add appropriate tests in `tests/membranes/` (test basic operations, edge cases, and integration with query orchestrator) |
| 149 | +5. Update documentation if needed (mention in membrane types overview) |
| 150 | +6. Consider if the new membrane type should participate in hybrid queries (update `QueryOrchestrator` if needed) |
| 151 | + |
| 152 | +### Developing for Edge Devices |
| 153 | +1. **Memory Optimization**: Use `palloc` for arena-style allocation; avoid unbounded growth |
| 154 | +2. **Flash Longevity**: Favor sequential writes; minimize random I/O operations |
| 155 | +3. **Deterministic Latency**: Avoid blocking operations; keep operations bounded and predictable |
| 156 | +4. **Power Efficiency**: Profile CPU usage; leverage SIMD instructions when available |
| 157 | +5. **Testing on Target Hardware**: Use scripts in `benchmarks/` to validate performance on actual edge devices |
| 158 | +6. **Verify No System Calls**: Run `./scripts/check_no_malloc_new.sh` to ensure proper memory practices |
| 159 | + |
| 160 | +### Modifying Storage Layer (Edge-Optimized) |
| 161 | +1. Changes typically affect `src/core/storage/` |
| 162 | +2. Ensure WAL consistency and crash-recovery properties are maintained (critical for power-loss resilience) |
| 163 | +3. Run soak/power-loss tests (see `tests/storage/`) |
| 164 | +4. Verify append-only property and tombstone handling (no random writes) |
| 165 | +5. Test with `./scripts/edge_release_print_sizes.sh` to check binary footprint |
| 166 | +6. Validate performance characteristics with `./scripts/run_benchmarks_one_by_one.sh` |
| 167 | + |
| 168 | +### Working with RAG Pipeline (On-Device AI) |
| 169 | +1. Core logic in `src/core/rag/` |
| 170 | +2. Embedding provider interface in `include/pomai/rag/embedding_provider.h` (implement for local models) |
| 171 | +3. Chunking strategies in `src/core/rag/chunking/` (optimize for zero-copy on edge) |
| 172 | +4. Test with `scripts/rag_smoke.py` |
| 173 | +5. Verify memory limits are respected (palloc integration) |
| 174 | +6. Test end-to-end pipeline: ingest → embed → store → retrieve → generate |
| 175 | + |
| 176 | +### Building Language Bindings for Edge |
| 177 | +- Python: Located in `sdk/python/` - uses ctypes by default (minimal footprint) |
| 178 | +- For richer APIs on edge, consider minimal pybind11 or custom C-compatible wrappers |
| 179 | +- Follow existing patterns in `sdk/` for new bindings |
| 180 | +- Consider creating lightweight bindings for microcontrollers if needed |
| 181 | + |
| 182 | +### Adding Edge-Specific Features |
| 183 | +1. **Connectivity**: HTTP endpoints in `src/edge_connectivity/` (health, metrics, ingestion) |
| 184 | +2. **Authentication**: Token-based auth mechanisms in edge connectivity layer |
| 185 | +3. **Hardware Features**: Utilize platform-specific optimizations (NEON, AVX2, etc.) |
| 186 | +4. **Wear Leveling**: Extend write-byte counters in storage layer for flash endurance |
| 187 | + |
| 188 | +## Testing Guidelines |
| 189 | +- Unit tests: GoogleTest framework in `tests/` |
| 190 | +- Integration tests: Focus on cross-membrane operations and recovery scenarios |
| 191 | +- Benchmark tests: Located in `benchmarks/` - measure throughput and latency |
| 192 | +- Sanitizer builds: Enable ASan/UBSan/TSan via CMake for CI-like testing locally |
| 193 | +- Always run `./scripts/check_no_malloc_new.sh` to ensure proper memory allocation practices |
| 194 | + |
| 195 | +## Logging and Diagnostics |
| 196 | +- Structured logging in `src/util/logging.*` |
| 197 | +- Log levels: DEBUG, INFO, WARN, ERROR |
| 198 | +- Use `POMAI_LOG(level)` macros for conditional logging |
| 199 | +- Inspect builds: `src/core/inspect.cc` provides runtime introspection |
| 200 | +- Health checks: Built-in HTTP endpoint (`/health`) when Edge connectivity features are enabled |
0 commit comments