The Search Router That Saved Me From One Index to Rule Them All: Azure AI Search for CRM, pgvector for Transcripts, the CRM a...
I noticed it the first time a "simple" search request turned into an argument between three databases. A sales rep asked for "forklifts in Texas with 10,000+ lb capacity under active warranty," and...

Source: DEV Community
I noticed it the first time a "simple" search request turned into an argument between three databases. A sales rep asked for "forklifts in Texas with 10,000+ lb capacity under active warranty," and I realized I could answer that question three different ways—each one correct in isolation, and each one wrong in production for a different reason. Azure AI Search could do synonym expansion and semantic reranking over my CRM-shaped records. Postgres + pgvector could do fast similarity over Zoom transcripts without duplicating data into yet another index. And the CRM—the messy, real-time source—was sometimes the only place the newest truth existed. This is Part 8 of my series "How to Architect an Enterprise AI System (And Why the Engineer Still Matters)". Part 7 was about building a reliable sync engine against a CRM API with undocumented behaviors. This one is what I built on top of that: a search router that decides, per query, which backend deserves the job. The key insight (and why the