Vector database product design consultant

Vector database decisions get framed as infrastructure choices and made by whoever set up the prototype. Six months later they surface as product problems: search that can't filter by the fields users care about, costs that scale faster than revenue, a migration nobody budgeted for. The design work I do sits exactly at that seam — choosing and shaping vector infrastructure from the product requirements backward.

Production experience, both directions

At WisOwl AI I built our semantic matching engine using both FAISS and Supabase pgvector — FAISS where raw similarity speed on large candidate sets mattered, pgvector where matches needed to live next to relational truth (roles, salaries, availability) with transactional integrity. That combination serves 5,000+ users and the recruiter partnerships our business runs on. The single biggest lesson: metadata design matters more than engine choice. Real product queries are never "find similar vectors" — they're "find similar candidates who are available, in this city, under this budget." If filterable attributes aren't designed into the schema from day one, every future product feature fights the infrastructure.

What the design engagement covers

• Engine selection with receipts: pgvector versus FAISS versus managed services, scored against your actual scale, latency budget, filtering needs, team size, and ops appetite — not against benchmark-marketing. (Spoiler: under a few million vectors with Postgres already in the stack, pgvector wins more often than vendors would like.)
• Schema and metadata architecture: what gets embedded, what gets stored as filterable attributes, how embeddings version when models change — the decision that quietly determines your future roadmap's degrees of freedom.
• Index and freshness strategy: HNSW parameters, recall/latency trade-offs mapped to UX (a matching product and an autocomplete have different truths), and how quickly new documents must become searchable.
• Cost model: embedding generation, storage, and query compute projected against your growth curve, with the re-embedding cost of a model migration priced in from the start.

Typically two to three weeks: I deliver the architecture, the decision log explaining every trade-off, and a review cadence with your engineers through implementation. A decade of product management means the deliverable optimizes for shipped user value — not for the most interesting infrastructure.

Frequently asked questions

Do we even need a dedicated vector database?

Often not. If you're on Postgres and under a few million vectors, pgvector gives you semantic search inside the database you already operate, with real WHERE clauses. Dedicated engines earn their place at scale, at strict latency budgets, or for advanced hybrid features — I'll show you where your numbers fall.

What happens to our vectors when embedding models improve?

You re-embed — so the corpus must be re-embeddable by design: raw text retained, embeddings versioned, dual-index migration path planned. Teams that skip this pay for it precisely when a better model would otherwise be a free upgrade.

How do you handle filtered vector search performance?

Filtering strategy is part of the schema design: pre-filter versus post-filter behavior differs by engine and selectivity, and highly-selective filters can gut recall if bolted on. This is a top-three source of "search suddenly got bad" bugs, and we design against it up front.

Can you review an architecture our team already proposed?

Yes — a one-week design review: I pressure-test the proposal against your product roadmap, latency and cost math, and migration story, and deliver a written assessment. Cheap insurance before infrastructure commitments harden.

Related pages