There are a lot of pgvector MCPs out there. Some of them are genuinely well-built — clean abstractions, auto-embedding, semantic search in a few tool calls. If you’re scaffolding a quick RAG prototype or want vectors without thinking too hard about the plumbing, they do what they say.
We don’t use one. Here’s why that’s the right call.
What a Dedicated pgvector MCP Actually Does
A dedicated pgvector MCP wraps your vector database in a set of higher-level tools: store a document, search by text, manage collections. The MCP handles the embedding call, the INSERT, and the similarity query. You never write SQL.
That abstraction is genuinely useful — until it isn’t.
The moment you need to JOIN your vector results against a sessions table, filter by agent name, or blend semantic similarity with full-text ranking, you’ve hit the ceiling. The abstraction that made it easy also made it shallow.
The O-Matic Architecture: The DB Is the Brain
O-Matic doesn’t treat the vector store as a separate layer bolted onto the factory. The Postgres cabinet is the factory — sessions, tasks, agent state, known rules, conversation history, and vectors all live in the same database, addressable by the same connection.
The plain Postgres MCP gives us full SQL expressiveness against all of it. That’s the design.
What lives in the schema:
semantic_index— 1536-dim vectors (OpenAI text-embedding-3-small), HNSW index, embed-on-write triggersdocument_chunks— chunked document corpus, same vector treatmentfn_search_semantic()— cosine similarity search against the semantic indexfn_search_documents()— hybrid search: semantic similarity + full-text, fused with Reciprocal Rank Fusion (RRF, k=60)v_startup_summary— factory state view that JOINs sessions, tasks, agents, and embedding health in a single queryv_agent_agreement— agent identity and rules loaded at activation
These aren’t queries. They’re the factory’s cognitive architecture, baked into the schema itself.
The RRF Difference
Most pgvector MCPs do cosine similarity and call it semantic search. That’s not wrong — but it’s incomplete.
Pure vector similarity finds documents that are conceptually related to your query. Full-text search finds documents with the actual words. Neither alone handles the edge cases well.
fn_search_documents() runs both paths and fuses the rankings using Reciprocal Rank Fusion with k=60. A document that ranks highly on both signals rises to the top. A document that’s semantically adjacent but doesn’t contain the relevant terms gets appropriately discounted.
This is meaningfully better retrieval — not marginally better. The difference shows up most on precise technical queries where the exact terminology matters, which is exactly what a factory full of agents running against SOPs and architecture specs needs.
Embed-on-Write
The factory doesn’t embed manually. Triggers on semantic_index and document_chunks call the embedding function automatically on INSERT or UPDATE. When a new document lands in the corpus, it’s vectorized before the transaction closes.
A dedicated pgvector MCP would handle this at the MCP layer — meaning the embedding lives outside the database’s transactional guarantees. The O-Matic approach keeps embedding atomically coupled to writes. The vector is never out of sync with the document.
One Connection, Everything
A dedicated pgvector MCP requires a second MCP connection — one for vectors, one for everything else. Or you use only the pgvector MCP and lose direct access to the rest of your schema.
The plain Postgres MCP gives a single connection to everything. Agents don’t switch tools to move from a semantic search to a task lookup. The factory’s entire memory — procedural, episodic, semantic — is one SQL query away.
This matters at scale across multiple factories. The same cabinet image runs omatic, homeatic, lucidit, practicallyadventist, and seomatic. Same schema pattern, same query functions, same startup view. Five factories, one architecture, zero pgvector MCPs.
When a Dedicated pgvector MCP Makes Sense
If you’re building a standalone RAG pipeline with no relational context — just “store text, search text” — a dedicated pgvector MCP is the right tool. The abstraction serves you.
If your agents need memory that JOINs, filters, aggregates, and reasons across multiple data types in the same transaction, you want the plain Postgres MCP and you want your search logic in the schema where it belongs.
The factory is the second thing. So that’s what we built.
O-Matic is a modular operating system for AI platforms. Built for real work, not demos.
o-matic.io
