Services

Vector & semantic search.

Semantic and vector search with pgvector and Postgres — meaning-based retrieval, hybrid ranking and RAG-ready foundations. NZ-based, working globally.

Keyword search fails the moment people don't use your exact words. We build semantic and vector search that retrieves on meaning — embeddings, similarity, and hybrid ranking that blends the new with proven keyword relevance — so users and AI assistants find the right thing even when they phrase it differently, drawing from one well-curated index.

Where we help

Vector search with pgvector in PostgreSQL — no extra database to run
Embedding pipelines that keep the index fresh as content changes
Hybrid ranking that blends keyword and semantic relevance
Chunking, metadata and filtering strategies tuned to your content
Retrieval foundations for RAG and LLM-backed assistants
Recommendations and similarity search over products or documents
Relevance evaluation and tuning against real queries
Graph-aware retrieval with Neo4j where relationships drive results

Example builds

Domain-specific models. We build custom neural networks, so we are comfortable with embeddings, similarity and the maths under vector search rather than treating it as a black box.

Search over private data. Semantic search often runs over sensitive records. Our privacy-focused CRM shows how we keep retrieval useful while access control and data boundaries stay firmly intact.

Findable knowledge. We built full-stack data systems where making large, messy corpora actually searchable — not just stored — was the whole point.

How we engage

We default to pgvector inside Postgres, because for most teams a separate vector database is operational overhead they don't need — your embeddings live beside the data they describe, with one backup and one access model. We build the embedding pipeline to keep the index current, blend semantic and keyword signals for hybrid relevance, and reach for Neo4j when relationships between items matter as much as their content. It is the retrieval foundation that RAG and assistants stand on. Single source, plural truths. See our services for how we scope.

Common questions

Do we need a dedicated vector database?: Usually not. pgvector in your existing Postgres handles the great majority of workloads with far less to operate. We only recommend a specialist vector store when scale or latency genuinely demand it, rather than by default.
How is this different from RAG?: Vector search is the retrieval engine; RAG is one thing you build on top, feeding retrieved context to a language model. Get search relevance right first and the assistant on top is dramatically better.
Can semantic search run over confidential data?: Yes. We enforce access control and tenant boundaries at retrieval time so results respect permissions, and we can keep embeddings and inference inside your own environment where the data requires it.

Data architecture Warehouses & lakehouses Streaming & event sourcing

Considering this for a project?

Start a conversation

Where we help

Vector search with pgvector in PostgreSQL — no extra database to run
Embedding pipelines that keep the index fresh as content changes
Hybrid ranking that blends keyword and semantic relevance
Chunking, metadata and filtering strategies tuned to your content
Retrieval foundations for RAG and LLM-backed assistants
Recommendations and similarity search over products or documents
Relevance evaluation and tuning against real queries
Graph-aware retrieval with Neo4j where relationships drive results

Example builds

Domain-specific models. We build custom neural networks, so we are comfortable with embeddings, similarity and the maths under vector search rather than treating it as a black box.

Findable knowledge. We built full-stack data systems where making large, messy corpora actually searchable — not just stored — was the whole point.

How we engage

Common questions

Do we need a dedicated vector database?

Usually not. pgvector in your existing Postgres handles the great majority of workloads with far less to operate. We only recommend a specialist vector store when scale or latency genuinely demand it, rather than by default.

How is this different from RAG?

Vector search is the retrieval engine; RAG is one thing you build on top, feeding retrieved context to a language model. Get search relevance right first and the assistant on top is dramatically better.

Can semantic search run over confidential data?

Yes. We enforce access control and tenant boundaries at retrieval time so results respect permissions, and we can keep embeddings and inference inside your own environment where the data requires it.