# Semantica VectorStore Backends: Complete Guide to Supported Storage Engines

> Explore Semantica's supported VectorStore backends including FAISS, Weaviate, Qdrant, Pinecone, PgVector, Milvus and more. Access them all through a unified API for efficient data storage.

- Repository: [Semantica /semantica](https://github.com/semantica-agi/semantica)
- Tags: guide
- Published: 2026-09-09

---

**Semantica supports eight VectorStore backends including in-memory, FAISS, SQLite, Weaviate, Qdrant, Pinecone, PgVector, and Milvus, all registered in [`semantica/vector_store/registry.py`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/weaviate_store.py)): Connects to Weaviate instances (cloud or self‑hosted), enabling hybrid vector and semantic search capabilities.

- **Qdrant** ([`qdrant_store.py`](https://github.com/semantica-agi/semantica/blob/main/qdrant_store.py)): Interfaces with the Qdrant vector search engine, optimized for large‑scale similarity search with filtering.

- **Pinecone** ([`pinecone_store.py`](https://github.com/semantica-agi/semantica/blob/main/pinecone_store.py)): Thin wrapper around the Pinecone managed vector service, handling index management and upserts via the Pinecone SDK.

- **PgVector** ([`pgvector_store.py`](https://github.com/semantica-agi/semantica/blob/main/pgvector_store.py)): Leverages the PostgreSQL `pgvector` extension to store and query vectors within a relational database schema.

- **Milvus** ([`milvus_store.py`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/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:

```text
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)

```python
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

```python
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

```python
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`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/semantica/vector_store/registry.py) automatically resolves the string to the correct class (e.g., `"qdrant"` maps to `QdrantStore` in [`qdrant_store.py`](https://github.com/semantica-agi/semantica/blob/main/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`](https://github.com/semantica-agi/semantica/blob/main/vector_store.py).