Semantica VectorStore Backends: Complete Guide to Supported Storage Engines

Semantica supports eight VectorStore backends including in-memory, FAISS, SQLite, Weaviate, Qdrant, Pinecone, PgVector, and Milvus, all registered in semantica/vector_store/registry.py and accessible via a unified API.

The semantica-agi/semantica repository provides a pluggable vector storage abstraction that allows developers to swap persistence engines without changing application logic. The core VectorStore class discovers concrete implementations through a registration mechanism in the semantica/vector_store/ directory. Each backend filename corresponds directly to a supported storage engine, enabling instantiation via the backend parameter string.

Supported Backends Overview

Semantica ships with concrete implementations for diverse deployment scenarios, from ephemeral memory stores to production-grade vector databases:

• In‑memory (vector_store.py): The default pure‑Python implementation that maintains vectors in RAM. Ideal for testing, development, and small‑scale workloads where persistence is not required.

• FAISS (faiss_store.py): Integrates Facebook AI Similarity Search for high‑performance approximate nearest neighbor search. Supports both in‑memory and on‑disk index serialization.

• SQLite (sqlite_vec_store.py): Persists vectors in a local SQLite database file. Provides a lightweight, zero‑configuration option for single‑node deployments.

• Weaviate (weaviate_store.py): Connects to Weaviate instances (cloud or self‑hosted), enabling hybrid vector and semantic search capabilities.

• Qdrant (qdrant_store.py): Interfaces with the Qdrant vector search engine, optimized for large‑scale similarity search with filtering.

• Pinecone (pinecone_store.py): Thin wrapper around the Pinecone managed vector service, handling index management and upserts via the Pinecone SDK.

• PgVector (pgvector_store.py): Leverages the PostgreSQL pgvector extension to store and query vectors within a relational database schema.

• Milvus (milvus_store.py): Connects to Milvus clusters or standalone instances, designed for billion‑scale vector collections.

Backend Registration Architecture

The semantica/vector_store/registry.py file maintains a mapping between backend name strings and their corresponding class implementations. When you instantiate VectorStore(backend="qdrant"), the registry resolves the string to the QdrantStore class defined in qdrant_store.py. This decoupling allows the public API to remain storage‑agnostic while supporting dynamic backend selection at runtime.

All concrete implementations reside in the semantica/vector_store/ package and implement a common interface exposing add_vectors, search_vectors, and delete_vectors methods.

Source Code Structure

The following files constitute the vector storage layer in the repository:

semantica/vector_store/
├── vector_store.py      # Core façade and in‑memory backend

├── registry.py          # Backend registration and resolution logic

├── faiss_store.py       # FAISS integration

├── sqlite_vec_store.py  # SQLite persistence

├── weaviate_store.py    # Weaviate client wrapper

├── qdrant_store.py      # Qdrant client implementation

├── pinecone_store.py    # Pinecone service integration

├── pgvector_store.py    # PostgreSQL pgvector extension support

└── milvus_store.py      # Milvus database connector

Practical Implementation Examples

In‑Memory Backend (Default)

from semantica.vector_store import VectorStore

# Default backend requires only dimension specification

store = VectorStore(backend="inmemory", dimension=384)
store.add_vectors(ids=[1, 2], vectors=[[0.1]*384, [0.2]*384])
results = store.search_vectors(query=[0.15]*384, top_k=2)

Qdrant Backend

store = VectorStore(
    backend="qdrant",
    config={
        "dimension": 384,
        "host": "localhost",
        "port": 6333
    }
)

# API remains identical regardless of backend

store.add_vectors(ids=[1, 2], vectors=[[0.1]*384, [0.2]*384])

PostgreSQL PgVector Backend

store = VectorStore(
    backend="pgvector",
    config={
        "dimension": 384,
        "connection_string": "postgresql://user:pwd@localhost:5432/semantica"
    }
)
store.delete_vectors(ids=[1])

Summary

• Semantica provides eight production‑ready backends ranging from ephemeral memory stores to distributed databases.
• Backend selection occurs via the backend parameter in the VectorStore constructor, resolved through registry.py.
• All implementations follow a uniform interface (add_vectors, search_vectors, delete_vectors) located in semantica/vector_store/.
• File naming follows the pattern {backend}_store.py for every supported engine except the default in‑memory implementation.

Frequently Asked Questions

How do I switch between backends in Semantica?

Change the backend string passed to the VectorStore constructor and provide the appropriate config dictionary for connection parameters. The registry in semantica/vector_store/registry.py automatically resolves the string to the correct class (e.g., "qdrant" maps to QdrantStore in qdrant_store.py).

Which backend is best for production use?

For high‑throughput, low‑latency applications, FAISS (local) or Milvus (distributed) provide optimized approximate nearest neighbor search. For managed infrastructure, Pinecone or Weaviate offload operational overhead. PgVector suits environments already running PostgreSQL.

Does Semantica support hybrid search across multiple backends?

The VectorStore abstraction operates against a single backend instance. To query multiple backends simultaneously, instantiate separate VectorStore objects for each backend and aggregate results at the application layer using the standard search_vectors API.

Where are the backend implementations located?

All concrete implementations reside in the semantica/vector_store/ directory within the semantica-agi/semantica repository. Each backend has its own file following the naming convention {backend}_store.py, while the core abstraction lives in vector_store.py.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}