We embedded a full Qdrant vector database into our local CLI to enable semantic search across our knowledge base. It worked perfectly in isolated tests, but in production, it immediately destroyed the two things our users cared about most: memory footprint and result freshness.

Sometimes, adding the “right” technology at the wrong time is worse than not adding it at all.

The UX Cost of Embeddings

In Equill, our primary interface was a fast, lightweight CLI. Users expected instant responses and a negligible memory footprint.

When we integrated local embeddings, the CLI had to spin up the vector engine and load the models into RAM just to process a simple query. A tool that used to consume megabytes was suddenly demanding hundreds of megabytes.

Worse, it killed freshness. Because FTS (full-text search) updates instantaneously while vector indexing requires batching and processing time, our hybrid searches began returning disjointed results. The vector index was always slightly behind the text projection. Users would add a note and immediately search for it, only to find the vector engine silently returning zero results because the index hadn’t caught up.

Stabilize Before You Scale

We made a hard architectural call: we completely ripped Qdrant and local embeddings out of the codebase.

We deliberately postponed vectorization. Instead, we doubled down on stabilizing the core CLI, relying strictly on blazing-fast SQLite FTS projections. We traded the magic of semantic similarity for absolute determinism, instant freshness, and a tiny memory footprint.

Advanced features cannot come at the cost of core UX. Stabilize your foundation before you add the heavy machinery.

---

Next up: we shift gears from databases to game development, exploring what it’s like to build a game with a 9-year-old art director in the DOOOORS series, starting with Child as Art Director.

• #equill
• #vector-search
• #architecture
• #engineering