Skip to content
WeftKitBeta

Database Modules

WeftKit provides 8 specialized database engines, each optimized for a specific data model. All share the same crash-safe storage kernel.

Module Overview

| Module | Type | Wire Protocol | Key Metric | |--------|------|---------------|------------| | WeftKitRel | SQL / Relational | PostgreSQL v3 | ~1.6 μs SQL parse | | WeftKitVec | Vector / ANN | gRPC | ~234 μs flat search (100 vectors) | | WeftKitKV | Key-Value | DynamoDB REST | ~204 ns point get | | WeftKitDoc | Document | MongoDB Wire | ~3.1 μs insert | | WeftKitGraph | Graph | Bolt (Neo4j) | ~15 μs BFS 100 vertices | | WeftKitMem | In-Memory | Redis RESP3 | ~116 ns point read | | WeftKitMD | Markdown | REST API | ~18.6 μs BM25 search | | WeftKitFile | File / Object | S3 REST | ~50 μs download |

Choosing a Module

Use WeftKitRel when you need SQL, ACID transactions, and complex joins.

Use WeftKitVec when you need similarity search for embeddings or RAG pipelines.

Use WeftKitKV when you need the fastest possible point reads/writes with optional TTL.

Use WeftKitDoc when your data is hierarchical JSON with MongoDB-compatible queries.

Use WeftKitGraph when your data is primarily relationships requiring traversal algorithms.

Use WeftKitMem when you need sub-microsecond latency and data fits in memory.

Use WeftKitMD when your content is Markdown and you need full-text search and versioning.

Use WeftKitFile when you need content-addressable storage with deduplication.

Using Multiple Modules

Each module is a separate Docker image. Run them side by side — every engine keeps its own data volume and exposes its own wire protocol port.

bash
docker run -d -p 20000:20000 -v rel-data:/var/lib/weftkit/data \
  weftkit/relational:0.1.0

docker run -d -p 20005:20005 -v vec-data:/var/lib/weftkit/data \
  weftkit/vector:0.1.0

No lateral dependencies between modules — you can run any combination safely. For a single entry point across engines, front them with the weftkit/gateway image.