feat(blog): add SQLite FTS5 + Dense hybrid retrieval article

[ishwar170695]

Changes proposed

Adds a new, technical, practitioner-led article to the Kubesimplify blog focusing on hybrid retrieval architectures in local RAG systems.

• New: content/blog/sqlite-fts5-dense-hybrid-retrieval.md — Deep-dive into sparse vs. dense search limitations, SQLite FTS5 BM25 configurations, Reciprocal Rank Fusion (RRF), deterministic domain reranking, and vector cache memory footprints.
• New: public/img/blog/sqlite-fts5-dense-hybrid-retrieval/ — Static assets (architecture diagrams, benchmarks, UI screenshots).
• Modified: content/authors.json — Add author profile entry for ishwar.
• New: public/img/authors/ishwar.jpg — Author avatar placeholder.

No other changes are made to the site's code.

Note to reviewers

This post focuses on systems-level search engineering and database schemas (SQLite), which is well-suited for KubeSimplify's backend, cloud-native, and infrastructure audience.

[saiyam1814]

Thanks for putting this together. I read through the article and the added assets. Overall, this is a strong technical draft: it has a clear retrieval problem, a concrete architecture, code snippets, benchmark numbers, screenshots, and a useful tradeoff section. I think it can fit the KubeSimplify audience well if we frame it as AI infrastructure / backend retrieval engineering rather than only as a generic RAG article.

A few changes I would suggest before publishing:

1. Use the architecture diagram in the article
   The PR adds public/img/blog/sqlite-fts5-dense-hybrid-retrieval/architecture.png, but the post currently shows the pipeline as an ASCII diagram. This topic benefits a lot from a visual architecture diagram, so I would embed the image in the Architecture Overview section and optionally keep the text explanation around it.

2. Fix the author image
   public/img/authors/ishwar.jpg appears to be the same file as the blog cover.jpg. That looks accidental. Please replace it with an actual author avatar or a suitable placeholder image.

3. Add more context around the benchmark numbers
   The reported improvements are compelling (466 ms to 12 ms, 320 MB to 48 MB, 68% to 91% Top-5 retrieval), but they need enough context to be credible and reproducible. Please add details such as corpus size, hardware, Node/SQLite versions, embedding model/vector dimension, how the 100-query benchmark was constructed, and how relevance was judged.

4. Verify math rendering for the RRF formula
   The post uses $$...$$ for the RRF equation. Please verify this renders correctly in the KubeSimplify site. If math rendering is not enabled, convert it to a plain-text/code-block formula so readers do not see raw LaTeX.

5. Make the KubeSimplify fit more explicit
   I would add a short section on where this belongs operationally: local-first backends, edge apps, small/medium corpora, Kubernetes workloads with persistent storage, serverless constraints, and when teams should move to Qdrant/Milvus/Elasticsearch. This would connect the article more strongly with KubeSimplify’s cloud-native/infrastructure audience.

6. Add a note on FTS5 table population/sync
   The SQLite FTS5 external-content table example is useful, but readers may wonder how sections_fts stays in sync with sections. A short ingestion snippet or note about triggers/rebuild flow would make the implementation more complete.

7. Polish the style for KubeSimplify
   Consider removing emojis from section headings and using a cleaner tutorial/deep-dive style. The current content is good, but simpler headings would make it feel more consistent with existing KubeSimplify technical posts.

Overall: this is close and worth publishing after the above polish. The idea is useful, the implementation is practical, and the performance/tradeoff framing is exactly the kind of detail readers will appreciate once the claims and visuals are tightened up.

[ishwar170695]

@saiyam1814 Thanks for the detailed review. I've addressed all the suggested changes:

• Embedded the architecture diagram and cleaned up the section headings.
• Replaced the incorrect author image with a custom author avatar.
• Expanded the benchmark methodology with corpus size details (~4,900 sections), hardware specifications (AMD Ryzen 5 5600H), software versions (Node.js v22.x, SQLite v3.x), embedding model details, and target relevance metrics.
• Replaced the LaTeX RRF equation with Markdown-friendly plain text code block formatting.
• Added an Operational Fit section covering local-first, Kubernetes sidecar workloads, serverless endpoints, and when to scale up to distributed vector databases.
• Documented FTS5 synchronization using SQLite trigger templates and rebuild commands.
• Aligned schemas/snippets with the actual codebase variables and table names (laws and laws_fts instead of the illustrative sections/sections_fts placeholders).

I also verified that the site builds successfully with these changes. Thanks again for the suggestions!

[saiyam1814]

Did you test this on real hardware?

[ishwar170695]

Did you test this on real hardware?

Yes. I tested everything on my local machine.

[saiyam1814]

for some reason I am not able to see the preview on cloud flare, let me pull in locally and check

[shkatara]

@saiyam1814 @ishwar170695 Here's the preview for the current state of the PR https://post-sqlite-fts5-dense-hybri.website-dab.pages.dev/sqlite-fts5-dense-hybrid-retrieval