Daniel Howells

Vector Search Everywhere

2026-01-25

I keep building the same thing. Wove searches museum collections by meaning. Blomma finds similar plants by appearance. Designround's Circle finds interior design inspiration from images. Massive recommends content based on what you've read. Different domains, identical architecture: embed content into vectors, store them in pgvector, query by similarity.

The pattern is always the same. Take a thing — an artwork, a plant photo, a product image, an article — and pass it through an embedding model that turns it into a 1,024-dimensional vector. Store that vector in Postgres alongside the regular relational data. When someone searches, embed their query the same way and find the nearest neighbours.

What makes this interesting is multimodal embeddings. Voyage's voyage-multimodal-3 can embed both images and text into the same vector space. So "melancholic winter landscape" and an actual painting of a bleak snowfield end up near each other, even though one is words and the other is pixels. This is what makes Wove work — you describe what you're looking for and it finds artworks that match the feeling, not just the keywords.

I use Neon's pgvector extension for all of this. No separate vector database. The vectors live in the same Postgres instance as the relational data, which means joins work naturally. Find me plants similar to this one that also grow in shade and flower in spring — that's a vector similarity query joined with regular WHERE clauses. One database, one query.

The cost is manageable. Embedding a batch of images is a one-time expense at ingest. The per-query cost is negligible because you're just embedding the search query and doing a nearest-neighbour lookup, which Postgres handles with an index. The expensive part is the initial embedding pass — Wove needs to process thousands of artworks from eight museum APIs, and each image costs a fraction of a cent. At scale it adds up, but for most projects it's surprisingly cheap.

The part I find most compelling is how the same infrastructure keeps finding new applications. Once you have vector search in your stack, you start seeing everything as an embedding problem. Product recommendations. Content personalisation. Visual similarity. Duplicate detection. The technique is the same every time — the domain is what changes.

I'm not sure where this ends. The embedding models keep getting better, the database support keeps getting more native, and the cost keeps dropping. A year ago I would have reached for Elasticsearch or Algolia for any search problem. Now my first instinct is pgvector and an embedding model, and it usually works better.