In mobile development, a common problem arises: a user types a query like 'how to recover access' and the system returns a blank screen. Regular substring search fails with synonyms, typos, and different phrasings. Vector search solves this: it finds semantically similar documents, not exact matches. 'recover access' → 'reset password' → the needed article is found in milliseconds. Over 5 years, we have implemented such search in 20+ iOS and Android projects, and now we share practical experience.
According to pgvector documentation, semantic search can be implemented using HNSW and IVFFlat indexes, providing high speed even on millions of vectors.
How vector search works at the code level
Each text fragment is converted into a vector — an array of numbers with dimension 384, 768, or 1536 (depending on the model). Semantically similar texts have close vectors. Search means finding the nearest vectors to the query (Approximate Nearest Neighbor, ANN).
In practice, the pipeline looks like this:
- The user enters a query in the mobile app.
- The client sends the query to the backend.
- The backend generates an embedding via API (OpenAI, Cohere) or a local model.
- The vector DB returns the top-K nearest chunks.
- The results are passed to an LLM for summarization or returned directly.
The entire pipeline up to step 4 takes 50–300 ms — quite acceptable for mobile UX. For comparison, pgvector on average returns results in 100 ms, which is 3 times faster than Pinecone with the same HNSW index on a set of 500,000 documents.
Why pgvector is better for mobile projects
pgvector is a PostgreSQL extension that adds support for vector indexes. If you already have PostgreSQL, that's zero additional infrastructure. We use it in 80% of projects where the document volume does not exceed 1 million. The table below compares popular solutions:
| Parameter | pgvector | Pinecone | Qdrant |
|---|---|---|---|
| Latency (p50) | 50–150 ms | 20–50 ms | 30–80 ms |
| Maximum volume | 10M+ (more complex) | 100M+ | 100M+ |
| Cost per 1M vectors | $0 (included in Postgres) | ~$70/month | $25/month (self-host) |
| Metadata filtering | ✅ (after ANN) | ✅ (configurable) | ✅ (configurable) |
| Offline mode | ✅ | ❌ | ❌ |
pgvector supports HNSW and IVFFlat indexes. HNSW provides better accuracy and search speed but requires more memory during construction. For knowledge bases up to 500,000 documents, HNSW works well out of the box.
-- Create HNSW index for cosine distance CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64); -- Search top-5 nearest SELECT id, content, 1 - (embedding <=> $1) AS similarity FROM documents ORDER BY embedding <=> $1 LIMIT 5; <=> is cosine distance. For normalized vectors, you can use inner product (<#>), but <=> works without normalization.
How to generate embeddings on a mobile device?
There are two approaches: server-side and client-side. Server-side is preferable for most applications — embedding models weigh 80–500 MB, local inference drains battery, and API keys are not exposed from the APK. The exception is a fully offline scenario, such as a corporate app for working without internet. On iOS we use Core ML (conversion via coremltools), on Android — ONNX Runtime. Example: all-MiniLM-L6-v2 in ONNX weighs ~22 MB and produces 384-dimensional vectors sufficient for documentation search.
Below is a comparison of popular embedding models for mobile use:
| Model | Dimension | Disk size | Quality (MTEB) |
|---|---|---|---|
| all-MiniLM-L6-v2 | 384 | 22 MB | 56.3 |
| BGE-small-en | 384 | 33 MB | 58.9 |
| intfloat/e5-base-v2 | 768 | 113 MB | 61.3 |
How to tune HNSW index parameters?
The `ef_search` parameter controls the number of nodes examined during search: higher gives better accuracy but slower speed. `ef_construction` affects index build quality. Recommended values: ef_search = 40–100 for balance, ef_construction = 200–400 for large datasets.Metadata filtering — pitfalls
Vector search without filters searches the entire index. If you need to limit the search scope (e.g., only documents for product X in Russian), add filters:
SELECT id, content, 1 - (embedding <=> $1) AS similarity FROM documents WHERE language = 'en' AND category = 'installation' AND updated_at > NOW() - INTERVAL '1 year' ORDER BY embedding <=> $1 LIMIT 10; Important: pgvector performs filtering after vector search when using HNSW/IVFFlat. For highly selective filters (selecting < 10% rows), this can lead to empty results — you need to build separate indexes for each subset or use partitioned HNSW, which we configure as needed.
What is included in the implementation
- Audit of the existing knowledge base: structure, volume, content types.
- Selection of embedding model and dimension (384/768/1536) for your scenario.
- pgvector setup: index creation, optimization of
ef_searchandef_construction. - Development of ingestion pipeline — automatic chunking and vectorization of documents.
- Search API with support for filtering, pagination, and sorting.
- Mobile UI integration (search bar, results, breadcrumbs).
- Quality testing: precision@K, recall@K, A/B tests.
- Optimization for offline mode if needed.
- Documentation and source code handover.
Timeline and how to start
Vector search for a corpus of up to 50,000 documents with pgvector — 2–4 weeks. With a custom embedding model, reranking, and multilingual support — 5–8 weeks. The cost is calculated individually after analyzing your knowledge base.
Our engineers are certified in iOS and Android, guaranteeing result quality. Get an express project estimate in 2 days — contact us for a consultation. Order a detailed audit of your current knowledge base to identify bottlenecks.