mnemo_postgres/lib.rs
1//! PostgreSQL + pgvector backend for mnemo (`StorageBackend` + `VectorIndex`).
2//!
3//! **Capability note — semantic recall is supported (v0.5.7, #99).** Embeddings
4//! are persisted to the pgvector `vector` column and, when [`PgVectorIndex`] is
5//! constructed with a pool ([`PgVectorIndex::with_pool`]), `semantic` / `auto`
6//! (hybrid) / `graph` / `domain_scoped` / `reconstruct` recall run a real
7//! cosine-distance ANN query against the `idx_memories_embedding_hnsw` HNSW
8//! index. The synchronous [`VectorIndex`](mnemo_core::index::VectorIndex) trait
9//! is bridged to async `sqlx` with `block_in_place` + `Handle::block_on`, so the
10//! Postgres vector path **requires the multi-threaded Tokio runtime** (the
11//! CLI/server is `#[tokio::main]`). `filtered_search` uses the same
12//! permission-safe oversample-then-filter as the USearch backend.
13//!
14//! If the pgvector extension / `<=>` operator is genuinely absent at runtime, or
15//! the index is built without a pool, the vector path still **fails loud** with a
16//! typed [`Error::BackendUnsupported`](mnemo_core::error::Error::BackendUnsupported)
17//! (`backend = "postgres"`, `capability = "semantic_recall"`) — never a silent
18//! empty result. The long-term async-`VectorIndex` refactor is tracked at
19//! <https://github.com/sattyamjjain/mnemo/issues/99>.
20
21pub mod migrations;
22pub mod pgvector_index;
23pub mod storage;
24
25pub use pgvector_index::PgVectorIndex;
26pub use storage::PgStorage;