The unfashionable choices
Building Genie, I made the same boring choice repeatedly:
- Postgres + pgvector instead of Pinecone, Weaviate, or Qdrant.
- Go stdlib HTTP + chi router instead of a full web framework.
- HS256 JWT in 150 lines instead of a JWT library.
- In-memory bus in development; Kafka in production. Same interface; swap at deploy.
- Single binary with embed.FS for the UI assets, instead of a separate frontend deployment.
None of these are surprising. None of them generate dev-twitter excitement. All of them are dramatically easier to operate at 2 AM when something has gone wrong.
What “boring” buys you
Reviewability. A regulator’s security team can read pgvector documentation in an afternoon. They can’t read a custom-built vector DB’s documentation in any amount of time, because it doesn’t exist. The boring choice has the documentation already written.
Hiring. Anyone with Postgres experience can debug a Genie issue. The specific-vector-DB experience is rare; you’d train every new hire.
Operational surface. Postgres has 30 years of operational tooling. The new vector DB has a Slack channel.
Predictable failure modes. When Postgres misbehaves, the failure mode is named in Postgres documentation. When the new system misbehaves, the failure mode is novel and you’re filing a GitHub issue.
What I gave up
- Cutting-edge performance. A purpose-built vector DB beats pgvector on raw recall+latency. By how much depends on the workload; usually 2-3× at the high end. For Genie’s workloads, never the bottleneck.
- Niche features. Some advanced ANN algorithms are pgvector-unsupported. We never needed them.
- Developer mindshare. The “we’re using Pinecone” pitch deck slide. Replaced with “we’re on Postgres” — which, for a regulator, is a better slide.
When boring is wrong
- Genuinely novel problem. If you’re doing something the boring stack can’t, the boring choice is wrong by definition. Most teams aren’t.
- The team has deep expertise in the exciting choice. A team that’s spent two years operating Kafka is faster on Kafka than on Pub/Sub. Pick what your team is fast on.
- The boring choice has known security issues. A library that’s been deprecated; a database with active CVEs. Boring means “well-trodden,” not “old and unmaintained.”
Where the choice paid back
Two specific moments:
A regulatory audit. The auditor asked “what’s the encryption story?” I said “envelope encryption with Postgres column-level KMS; here’s the page in the Postgres docs that describes the underlying primitives.” They read it. They signed off. The audit took an hour.
A 2 AM incident. Spanner was slow; one query was hot. I opened pgAdmin against the read replica, ran EXPLAIN, found the missing index. Fix shipped in 20 minutes. If the stack had been more exotic, the diagnosis alone would have taken longer.
The principle
For regulated AI specifically: the system you ship lives in operations for years. The reviewer who sees it lives in audit for days. The on-call who debugs it lives in 2 AM for minutes.
Optimise for the long stretches, not the demo. Boring wins on long stretches.
The exciting stuff has its place. Just make sure the place is the part where the audience is engineers excited about new technology, not regulators auditing a bank.