Build1 publisher2 min readPublished
A dedicated vector database adds a sync job to every write
A dev.to post argues that moving embeddings out of Postgres buys a second source of truth, a four-leg query path and 50 to 150 ms of internet latency. Its 8 ms pgvector counter-figure has no benchmark behind it.
The Engineer · Build desk
What happened
- A dev.to post argues almost no team needs a dedicated vector database, opening with a team that pays $300 a month for a managed index over 50,000 customer support documents.
- Its central objection is operational: the external index becomes a second source of truth fed by an async job, and a sync failure overnight leaves the RAG pipeline answering from stale or missing chunks.
- The counter-figure it offers is 8 milliseconds for the same 50,000 vectors from the team's existing PostgreSQL instance, retrieved with a single line of SQL and no added cost.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost At 50,000 vectors, $3,600 a year works out to roughly 7 cents per vector per year, and the queue or CDC pipeline that keeps that index current is paid separately, in engineering time.
- constraint Once embeddings sit outside Postgres, tenant, version and date filters can no longer be evaluated where the rows live, so the application layer becomes the join engine for every filtered query.
- decision Teams now choose between transactional deletes, where a document and its embedding disappear in one commit, and an external engine whose best case is eventual consistency.
- exposure Database-level authorization stops at the Postgres boundary, so tenant isolation has to be re-implemented as filter payloads crossing the public internet.
The 8 millisecond figure is a claim about someone else's machine [2]. For it to hold on yours, the corpus has to be around 50,000 vectors [1] at roughly the 1,536 dimensions the post uses as its working example [8], the index has to be warm, and your recall target has to match whatever that query accepted. The post publishes no benchmark: no index type, no hardware, no recall target [15]. It also never names the vector count at which a specialized engine starts to win [11].
Other stacks will reproduce the query path; they will not reproduce the latency. In the split architecture the post describes, a filtered RAG query crosses four legs: Postgres returns the authorized tenant document IDs, the backend ships those IDs to the external engine over the public internet as a filter payload, the engine returns chunk IDs, and the backend goes back to Postgres for the raw text and relational metadata [6]. One of those legs is priced, at 50 to 150 ms [6]. Divide by the 8 ms in-database query and that single hop costs between six and nineteen times the search it feeds [13].
Writes are where the cost recurs. Two systems means every mutation writes twice, and a Postgres commit that lands while the vector engine's API call times out leaves the two in drift [4]. The repair is a distributed queue, an Outbox table, or CDC, which the post puts at hundreds of lines of glue code with its own failure points [4]. Inside one database, deleting a document and deleting its embedding happen in the same BEGIN ... COMMIT block; across two, eventual consistency is the ceiling [5].
Consistency is the stronger half of the argument here, and it holds at any vector count. A sync job that fails at 03:00 serves stale or missing chunks at 09:00 whether the index holds 50,000 vectors or a great many more [3]. Speed is the half that will flip somewhere, at a vector count the post leaves unnamed. It grants the vendors one point, that the dashboard looks sleek [17]. Alongside consistency it lists the rest of the split-architecture cost: doubled storage, network latency on every query, and a security model spread across two systems [14].
What to watch
- A published pgvector benchmark that states index type, hardware, recall and vector count would settle the speed half of this argument. The post's 8 ms figure, on its own, leaves it open.