Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What LanceDB is
LanceDB is a developer-friendly, embedded vector database built on the open Lance columnar format. Rather than running as a separate server, it links directly into the calling application and reads and writes table files on local disk or an object store.
A table combines vector columns with arbitrary scalar columns in one structure, so vector similarity, full-text, and scalar filtering can all be queried together against the same data. Its own framing is a multimodal AI lakehouse: vectors alongside images, video frames, and other modalities, not vectors alone.
What it is normally used for
How LanceDB is used generally, before Synedrix OS enters the picture.
- Embedded RAG applications where the index needs to live inside the application process
- Multimodal retrieval: vectors stored alongside images, audio, or video in one table
- Local-first and edge deployments with no separate database server to operate
What it owns, and what it does not
Every platform in the stack has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- Nothing in production: reachable only from LAB-001's isolated environment, never from a registered agent
Does not own
- Semantic retrieval and similarity search: the single vector store
- → Qdrant (Layer 7)
- Canonical relational truth: entities, state, approvals
- → Supabase PG17 (Layer 7)
- Anything a registered agent may recall as memory
- → The governed memory fabric, never a lab component directly
Why LanceDB
Rejected as a duplicate store, not on capability
Synedrix OS already has a vector store. LanceDB is a capable embedded index, but adding it to the stack would mean two answers to the same question: the exact rule ADR-OS-002applies here, that keeps every platform's responsibility non-overlapping.
Inseparable from the runtime it ships in
EverOS's value as a memory runtime is inseparable from LanceDB and SQLite underneath it; unlike a library whose vector index can be scoped away and kept, dropping LanceDB here means dropping the feature EverOS exists to test.
Worth evaluating precisely because it is not adopted
LAB-001 exists to test, in isolation and on a time box, whether the practical cost of a second vector store is as high as that argument assumes, evidence gathered without reopening the decision to get there.
Licence position
LanceDB questions, answered
Short, citable answers drawn from this page.
What role does LanceDB play in Synedrix OS?
LanceDB (Embedded vector index (EverOS)) is mapped to Lab component: no OS layer in Synedrix OS. The embedded vector store EverOS ships with: evaluated in isolation, never in the stack.
What does LanceDB own in Synedrix OS?
LanceDB owns: Nothing in production: reachable only from LAB-001's isolated environment, never from a registered agent.
What does LanceDB not own in Synedrix OS?
LanceDB does not own: Semantic retrieval and similarity search: the single vector store (owned by Qdrant (Layer 7)); Canonical relational truth: entities, state, approvals (owned by Supabase PG17 (Layer 7)); Anything a registered agent may recall as memory (owned by The governed memory fabric, never a lab component directly).
The full reference page, with the operating model, deployment detail, and links to every canonical specification this platform touches, lives in the documentation repository, which is private while the platform is being built.