The argument for boring technology is not sentimentality. It is arithmetic.
When building Gitloom — a code analysis platform that runs semantic similarity search across entire GitHub repositories — I evaluated Pinecone for vector storage. The pitch was legitimate: Pinecone is faster than pgvector at 100M+ vectors, managed, with a clean API and sub-50ms global query latency via edge replicas. For a large-scale production system, it is the right answer.
We had 2 million vectors. Our p99 similarity query budget was 150ms. PostgreSQL with pgvector and an HNSW index delivered 95ms p99 against our actual corpus. The additional 45ms of headroom wasn't worth $70/month plus an external API dependency, an additional SDK, and an additional failure domain.
The same logic applied to Kafka. We were processing repository indexing jobs that needed to run asynchronously and survive application restarts. Kafka is the right tool at 100,000 events/second with multiple consumer groups. We needed 8,000 jobs/hour with one consumer. `SELECT ... FOR UPDATE SKIP LOCKED` in PostgreSQL is a job queue. It does not require broker management, consumer group coordination, offset commits, or a Confluent bill.
Apollo Federation was the hardest rejection because the GraphQL schema consolidation genuinely would have improved our client queries. But Apollo Federation requires a router service, a subgraph registry, and a deployment pipeline that understands service composition. We had three engineers. The organizational overhead would have consumed one of them.
The thing I had to learn: specialized tools solve problems at scale you do not yet have. Every specialized tool you adopt before that scale is debt you pay in operational complexity, monthly cost, and debugging time — because when the specialized tool breaks, you are reading its source code at 2:00 AM instead of writing product features.
PostgreSQL has twenty years of debugging tooling, documentation, and Stack Overflow answers. When our HNSW index rebuild slowed after a schema migration, the cause — a missing `fillfactor` setting — was in the PostgreSQL documentation. When your Pinecone index behaves unexpectedly, you file a support ticket.
Eighteen months after launch: $120/month in infrastructure, zero database partitions, zero vector search outages, zero broker restarts. The team spent zero hours on infrastructure debugging. All of that time went into the product. I would make the same decisions again.