I've championed pgvector as the sensible default for vector search. After running it in production, here's what the introductory tutorials leave out: index choice and its trade-offs, the recall-versus-speed dial, keeping embeddings in sync, and the operational realities that only show up at scale.
Once your semantic search outgrows a toy dataset, the question arrives: stay with pgvector in Postgres, or move to a dedicated vector database like Pinecone, Qdrant, or Weaviate? A deep-dive on what actually changes at scale, what you give up by leaving Postgres, and how to decide without over-engineering.
Keyword search matches words; semantic search matches meaning. A deep-dive on embeddings and vector similarity, and how pgvector lets you do semantic search in the Postgres you already run — no separate vector database required.
Getting search results back is easy; getting the right products in the right order is the real work. A deep-dive on relevance tuning for a store — boosting by business signals, synonyms, typo handling, zero-results, and measuring whether your changes actually help.
When a store needs search, the reflex is Elasticsearch — but Postgres full-text search has grown up. A head-to-head for the e-commerce case: ranking, facets, typo tolerance, and the operational cost that decides it.
SQL LIKE is not search. A deep-dive on adding real full-text search to a Rails app with Elasticsearch — analyzers, mappings, relevance, keeping the index in sync — and an honest take on when Postgres is enough instead.
Users misspell things, and exact matching fails them silently. A practical deep-dive into trigram-based fuzzy matching in Ruby — how it works, how to make it fast, and when to push it into Postgres instead.