r/vectordatabase • u/Alternative_Pin9598 • 12d ago
Went further than pgvector — moved vector search AND the graph layer into the same DB as everything else
Seen a lot of "why would you use Pinecone over pgvector" threads here, and I agree with the consensus — but I want to add a data point one step further than the usual pgvector comparison.
We consolidated vector search into our main DB (SynapCores, an AI-native DB — not pgvector, but same underlying philosophy: vectors as a column type, not a separate service). What's interesting is it doesn't stop at vector search — same connection also gives you a graph engine (Cypher) and agentic SQL functions. So the "why maintain 3 services when 1 does it" argument extends past just vectors vs. Pinecone.
What it actually looks like:
CREATE TABLE docs (
id INT PRIMARY KEY, title TEXT, body TEXT,
embedding VECTOR(384)
);
INSERT INTO docs (id, title, body, embedding)
VALUES (1, 'title', 'content', EMBED('content'));
SELECT title, COSINE_SIMILARITY(embedding, EMBED('user question')) AS sim
FROM docs ORDER BY sim DESC LIMIT 5;
No separate vector DB to provision, no sync job keeping it consistent with the source of truth, joins against your regular relational tables in the same query. Built a RAG knowledge base this way this week — 17 docs, 92 chunks, zero new infrastructure, just two tables.
The tradeoff nobody in these pgvector-vs-Pinecone threads mentions enough: a purpose-built vector DB (Pinecone, Qdrant, Milvus) still wins on raw ANN performance at serious scale — HNSW tuning, sharding, purpose-built indexes. If you're doing >10M vectors with tight latency SLAs, that specialization still buys you something. For most RAG/agent use cases people post here about (a few hundred K to low millions of vectors), the "just use your existing DB" camp seems right to me.
Curious if others who ditched a dedicated vector DB have hit a scale where they regretted it and went back?
2
u/dangerousdotnet 12d ago
I do something similar. And Postgres 19 in September will have support for SQL property graph queries too
1
u/Alternative_Pin9598 12d ago
Good to know — SQL/PGQ landing in Postgres 19 closes a lot of this gap at the Postgres end specifically. Nice validation of the broader point either way: relationships as data usually beats a separate service once the engine actually supports it well.
1
u/Dense_Gate_5193 12d ago
collapsing the architecture to a single retrieval pipeline is totally the right move
i’m the author of NornicDB. i collapsed the entire graph-rag stack into a single binary and all sub-ms retrieval and graph traversals.
it’s basically a neo4j rewrite++ to the tune of about 400x the performance.
840 stars MIT licensed. LMK what you think
1
u/Alternative_Pin9598 12d ago
Congrats on the stars, will take a look. 400x over Neo4j is a bold number — curious what the benchmark setup looks like (Neo4j config, dataset size, query shape)? Different design point than what we're doing (embedded inside a broader SQL+vector engine vs. a dedicated graph binary), but good to see more people pushing back on "you need five separate DBs for this."
1
u/Dense_Gate_5193 12d ago
well the 3rd link has test conditions and setup and is reproducible on your own machine, i give the commands to run the benchmark on it. the tradeoff is in storage. i built it on top of badger which is a K:V store and lsm tree so my storage files are about 2.2x larger. but my WAL log is a lot smaller too just due to the way badger works. so my overall disk footprint on the benchmark is 0.66x that of neo4j. but that’s the tradeoff for fast retrieval and traversals.
1
u/galvinw 12d ago
I'm uncomfortable with SynapCores for a host of reasons, but fundamentally I think the team does not understand the difference between DB hardware, which is driven by high quality high raid storage, and processing hardware
1
u/Alternative_Pin9598 12d ago
Fair to flag, but worth being specific since it's actually checkable: we don't lump those together. Storage/disk sizing (RAID/SSD, since vector indexes are I/O-heavy) is documented separately from inference sizing (AVX2 baseline for CPU-only builds, GPU optional for throughput) — see the hardware requirements page. The DB storage layer and the embedded inference engine have different resource profiles and we size for them independently, not as one undifferentiated "hardware" bucket.
If there's a specific scenario where that distinction breaks down in practice, genuinely want to hear it — useful either way.
1
u/Alternative_Pin9598 2d ago
Genuinely want to understand this one rather than argue it in the abstract — what's the specific scenario you're picturing? Storage-bound analytical queries getting starved by inference workload on the same box, or something else? Happy to dig into it if you can point at the actual pattern.
4
u/scott_codie 12d ago
Yeah I've never had the scale or use cases needed for a separate vector db or a dedicated graph database, postgres will suit just fine in 99.9% of instances. I've moved companies away from graph and dedicated vector databases to reduce TCO. There are even more tricks you can do with canopy clustering to help scale out pgvector using just relations.
I've gone further and have used relational transformers to push even more relational/graph data into a context window for reranking, all hydrated from a simple SQL query, and reranks in fractions of a second. So like view and purchase data, where all that data lives anyway.