# sqlite_search: Full-Text, Vector, and Hybrid Search for ActiveRecord

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | sqlite-rag-hybrid-search |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | sqlite_search: Full-text, vector, and hybrid search for ActiveRecord, without leaving SQLite |
| Source URL | https://github.com/radioactive-labs/sqlite_search |
| Source publisher / author | GitHub organization radioactive-labs |
| Source type | repository |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-09 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | web search synthesis |
| Confidence | Medium |
| Status | Active |

## Summary

A Ruby/ActiveRecord library adding full-text, vector, and hybrid search to a Rails app using only SQLite — no separate search service. Notably, its query parser strips FTS5 operator syntax out of untrusted input before it reaches SQLite, as a deliberate safety measure.

## Key findings

- Demonstrates the "search stays inside SQLite, no external search service" philosophy applied at the application-framework level (ActiveRecord/Rails), not just in a one-off script.
- Explicitly sanitizes/strips FTS5 query operator syntax from user input — a concrete, named security practice (preventing FTS5 MATCH syntax injection from untrusted search boxes).
- Offers full-text, vector, and hybrid modes as named options, implying all three were considered legitimate, supported configurations by the library's authors, not just a single blessed path.

## Pros / strengths

- The input-sanitization detail is a genuinely transferable, concrete security practice independent of the Ruby ecosystem: raw user text should never be handed to FTS5's MATCH operator unescaped.
- Evidence that "hybrid search entirely inside one SQLite file" is being productized as a reusable library, not only hand-rolled per project.

## Cons / limitations / caveats

- Ruby/ActiveRecord-specific; no architectural detail on its vector-search implementation (which extension, if any) was recoverable from the search synthesis.
- No benchmark or production-scale evidence was found during this research pass — only the existence and stated feature set of the library.

## Relevance to tai

The FTS5-input-sanitization point directly reinforced existing `tai` behavior worth double-checking: `tai.py`'s own `fts_escape()`/`fts_match()` functions already tokenize and quote search terms before building the FTS5 `MATCH` expression, which is the same defensive pattern this library implements independently. This source corroborated that `tai`'s existing approach (never passing raw user text into a MATCH clause) matches recognized practice elsewhere.

## Changelog

| Date | Change |
|---|---|
| 2026-10-09 | Initial dossier created. |