u/Alternative_Pin9598

Saw a thread a while back about "the most temporary thing that's now load-bearing in prod" and it got me thinking about a scarier version of that question — not the thing you know is fragile, but the thing that's already broken and reporting success anyway.

We found one of these in our own system a couple weeks ago. A scheduled automation job (running on our database engine, SynapCores) was supposed to log which tools it called before saving its own run history — except that record was silently getting stripped before it got written. So the next run looked at its own history, saw "no tools were called, that's fine," and copied the pattern. Run 1 worked. Run 10 did nothing and logged "success" anyway.

The scary part wasn't the bug — it was that nothing in monitoring caught it. Uptime was fine. Error rate was fine. The job just quietly stopped doing its job while reporting everything was great.

Made me realize how much of what we call "monitoring" only catches things that fail loudly.

Anyone else have a story like this — something technically "succeeding" while doing nothing useful, and how long did it run before someone caught it?

(Also — been away from this sub for a while. If anyone's still around, what are you working on these days?)

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?