Building a Search Engine for 6,000 Personal BlogsBuilding a Search Engine for 6,000 Personal Blogs<br>2026-08-03TL;DR: Semsearch is an embedding-based search engine whose corpus is bootstrapped from<br>indieblog.page's blog list. It aims to make indie<br>blogs more discoverable. At the time of writing, the live instance is up at semsearch.blog<br>with roughly 6,000 unique blog sites, 154k pages, and 1.4B tokens.<br>The source code is at github.com/yikerman/semantic-search.Motivation<br>The idea for this project emerged when I read about The Great Blogging Collapse<br>(HN discussion). While the post itself<br>has a couple of problems, its broader point resonated with me as a blogger: there are fewer ways<br>to promote small and individual blogs. In the past, many visits began when Google led users to<br>your blog. But Google, as shown in The Great Blogging Collapse, is doing so less and less<br>for various reasons, such as the rise of AI summarization that completely eliminates visits to<br>other sites.This aligns with other sources: people (including me) prefer searching on Reddit<br>since Google's top results are cluttered by ads and SEO-optimized content farms. For example, a<br>Google search for the old Postgres vs MySQL debate<br>returns mostly AWS and IBM articles that are of little use. (Interestingly, at the time<br>of writing, it seems that Google has boosted Reddit's ranking and put it among the top results.)Google Search for PostgreSQL vs MySQLWhile the debate has largely settled, this would have been the perfect scenario to display some<br>old-n-wise engineer writing about his experience with both in production, even if his webpage is<br>styled uglier than The Motherfucking Website.Recent embedding models have made it practical to search by meaning rather than exact keywords<br>(which also requires non-trivial tricks to work effectively), and vector databases have also<br>proven to be practical and easy to use. While most existing embedding-based search systems are<br>used to provide agentic LLMs with retrieval capabilities, I want to explore the possibility of using<br>purely embedding-based search to help people discover indie blogs.Implementation<br>I used FastAPI for the web app and Postgres + VectorChord<br>for the database. The set of blogs is bootstrapped from indieblog.page's blog list.<br>For each page discovered through either an RSS feed or a sitemap, I used Trafilatura<br>to extract the text content, then chunked it into overlapping 384-token segments. For the<br>embedding task, I chose Qwen3-Embedding-4B<br>as the embedding model, since it topped the MTEB leaderboard<br>at the time of writing, is open source, and is relatively cheap to run. Every chunk is stored in<br>the database as a 2,560-dimensional halfvec.At query time, Semsearch embeds the query once and runs designated retrievers. By default, only<br>the dense retriever, based on the cosine similarity between the query embedding and chunk embeddings,<br>is used, and the top 64 entries are returned. There is also an optional BM25[1]<br>retriever for both evaluation and combining results through RRF[2]<br>(Anthropic claims that the hybrid approach performs better[3]).<br>For details, see the search pipeline<br>and the SQL doing the heavy lifting.Deployment<br>Deployment is a bit tricky, since the HNSW index<br>takes about 30 GB of RAM to load at the current scale, and VPS costs scale a lot with RAM.<br>For reference, an r6a.xlarge instance on AWS costs $0.252/hr. I ended up getting a<br>dedicated i7-6700 box from Hetzner's server auction for €55/mo. While the CPU is crappy by modern<br>standards, it comes with 64 GB RAM and 2 × 512 GB NVMe SSDs, an absolute bargain in the RAMageddon era.I used OpenRouter's API to run the<br>embedding model, since it is relatively cheap, namely $0.02/M tokens. Indexing the current<br>corpus cost a modest $28.60, which is not bad. The latency and throughput are not<br>ideal, though: I get roughly 6,000 tokens/sec on OpenRouter, and it bottlenecked the initial<br>indexing process.Evaluation<br>So how do the results look? Going back to the earlier query of Postgres vs MySQL<br>(archived),<br>the results are mixed and sit somewhere between useful, fun, and nonsense.The first result is a<br>funny not-quite-a-failure. It is a cached Hacker News comment (why are you caching all the<br>content you bookmark on your blog, Nitsikopoulos?) from a submission about a company migrating from MongoDB to<br>PostgreSQL. The comment compares operating Postgres and MySQL at scale (while the submission<br>itself is, indeed, about MongoDB), which explains the high similarity score. The search works<br>and provides deep insights, but the presentation can be confusing to users in certain cases.The 2nd<br>and 3rd results are indeed very<br>relevant, but the writing is thin and of mediocre quality.The 4th result<br>is an old blog post dating back to 2002 and is the kind of fun content I would like to see. It is obscure<br>and based on firsthand experience, and much of the technical advice is now historical.The 5th result<br>is probably the strongest answer overall: Roztropiński has a detailed...