Projects / Multi-Model Databases
Subproject
HumemDB
A Python orchestration layer that combines SQLite, DuckDB, CypherGLOT, and LanceDB so table, graph, and vector workloads can be routed across embedded engines without forcing one database to do every job.
Routing
Route each workload to the embedded engine that already does it well.
Figure 1
Runtime routing model
- SQLite for OLTP writes and reads
- DuckDB for OLAP and analytical reads
- CypherGLOT for graph-query compilation
- LanceDB for vector index build and search
HumemDB is not trying to be one fake all-in-one database core. It is a Python orchestration layer that combines SQLite, DuckDB, CypherGLOT, and LanceDB so each workload can go to the engine that is already strong at it.
SQLite handles canonical writes and OLTP table workloads, DuckDB handles broader analytical reads and OLAP workloads, CypherGLOT provides the graph-query layer over that table-backed storage, and LanceDB adds the embedded vector path for index build and search.
Tables + Graphs
Keep one table-backed foundation for both table and graph queries.
Figure 2
Shared table-backed foundation
- One underlying table layout
- SQL over the stored tables
- Cypher views over the same data
- No separate duplicated graph store
Most systems that want tables, graphs, and vectors either duplicate data across separate stores or force everything through one engine and call it multi-model. That creates unnecessary complexity and often leaves developers maintaining separate table and graph representations of the same data.
HumemDB takes a table-first approach instead. SQLite and DuckDB remain the underlying table engines, while CypherGLOT lets those same table-backed layouts be understood and queried as graphs. Graphs are a view over the data, not a duplicated silo beside it.
Vectors
Add vector search without leaving the embedded model.
Figure 3
Embedded system composition
- Python orchestration layer
- Embedded table engines with Python bindings
- Graph-query layer via CypherGLOT
- Embedded vector indexing and search
LanceDB gives the stack an embedded vector path for index build and search, so vector workloads can live beside the SQL and graph-query paths instead of being pushed into a separate hosted service or duplicated system.
That makes HumemDB useful for memory-heavy AI systems that need tables, graphs, and vectors in one local runtime, while still keeping the routing model explicit and defensible.
Resources