The only stopwatch number in the post goes against the change it argues for: bare k nearest vectors, no filter, warm cache, and the dedicated store won every time [2]. There is no filtered p95 for the pgvector version, no recall figure, no bill [16]. The author says his own headline oversells the speed claim [17]. So the case for deletion rests on something other than latency, and it is worth being exact about what.
The two filtering strategies are the mechanism, and they are not a vendor defect. Pre-filter, and the store walks metadata first and brute-forces similarity over the survivors, which discards the approximate index you bought it for [4]. Post-filter, and it keeps the index but pays in recall: ask for 10, match on distance, find that 7 rows belong to another tenant, return 3 [5]. Over-fetching top 100 or top 500 does not bound the loss, because the shortfall depends on how badly the filter correlates with the vector space, and it is worst exactly when the filter is most selective [5]. Any approximate index meets that same fork when a WHERE clause arrives. Which fork Postgres took for their filtered query is not in the post, and it is the first thing I would measure before copying the architecture.
They had already conceded the read path in code. Post-filter, then fetch back to Postgres for the metadata the vector store did not hold, then filter again to be sure, on every query [6]. Two systems answering one question, one of them because the other could not.
The write path is where the deletion actually pays. The embedding is a pure function of the document body, derived the way a thumbnail is derived from an image, and it was living in a different database from its source [7]. Every write was two writes [8]. When the embed-and-upsert fails after the row commits, nothing throws and nothing alerts; the document quietly cannot be found, or is found by its old content [9]. Run it the other way and a delete in Postgres that fails in the vector store returns a chunk of a document that no longer exists, to a user who may no longer be cleared to see it [10]. The author's name for this is the dual-write problem, the seam the transactional-outbox literature has been on about for a decade [11].
The alternative to deleting the store is building the machine: tail the WAL, transform, re-embed, upsert, dead-letter the failures, and run a reconciliation scan because you know the pipeline drifts [12]. Six stages [14], and the sixth exists because you have already accepted that the first five do not hold. That was most of the 1,100 lines [12].
Adoption cost lands in your primary, because the replacement is a column on the table the application already reads [1]. Price it: 3.2M vectors [1] at 1536 dimensions [13] is 4.9 billion floats, and at four bytes each that is roughly 19.7 GB [15] before HNSW overhead, in your backups and on your replicas.
For that trade to transfer, three things have to be true of your workload: every retrieval carries a tenant or ACL predicate [3], the embedding is a pure function of a row you already own [7], and 20 GB plus an index in the primary is not a problem. If you genuinely search a whole corpus unfiltered, the benchmark the vendor wins is your query [2], and none of this applies.
