How would you design semantic search for hellointerview.com? I just answered this question in production yesterday. For those who follow our content, any guesses how I chose to implement it? The answer: 1. Add pgvector and pg_trgm extensions to our existing Postgres db - pgvector handles vector similarity search for embeddings, while pg_trgm provides traditional text search capabilities. This gives us both semantic search (understanding meaning) and fuzzy text matching. 2. Use OpenAI's text-embedding-3-small to create embeddings for each indexable page - We extract the main content from each page, send it to OpenAI's embedding model, and store the resulting 1536-dimension vector in a DocSearch table alongside the page title, URL, and content snippet. This lets us find semantically similar content even when exact keywords don't match. 3. To load the index, rely on Next.js exported page metadata - Next.js already has you export metadata for SEO (title, description, etc.). We statically extract this during build time and use it to identify what needs to be indexed, keeping our search index in sync with what's actually published. 4. To keep it up to date, created a GitHub action that runs on each deployment - The action compares current page metadata against what's in our database. If it detects changes (new pages, updated content, deleted pages), it automatically calculates new embeddings and updates the index. This means search stays current without manual intervention. 5. Query time combines both approaches - User searches trigger both a vector similarity search (for semantic matches) and traditional text search (for exact & fuzzy matches), then we merge and rank the results. Why not Elasticsearch like we talk about in many of our breakdowns? Small team, already using Postgres, and a growing but reasonably sized user base. No need for an extra infra headache. The real tradeoff I weighed was between rolling our own or using a SaaS offering like Typesense. I started integrating Typesense thinking $30/month would be worth the couple days saved, but while doing so, realized that the "hard" parts of content extraction, keeping the index synchronized with deployments, and handling updates still needed to be solved regardless of the search backend. Once I saw we'd have to build those systems anyway, implementing the actual search with our existing Postgres setup took less than a day. | 22 comments on LinkedIn