Platform · Retrieval

KERNSTACK Vector search

Vector search on KERNSTACK is the retrieval half of search: a search_indexes entry with index_type "vector" over your tables and buckets, embedded with the catalogue model text-embed-v1 (3 credits per 1,000 tokens) or a custom inference endpoint. The vectors live where the records live, which deletes the second database, the sync pipeline, and the second vendor from the architecture.

Vector Search

Talk to us Read Vector search Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Vector search

Teams otherwise run a separate vector database vendor: embeddings upserted by a pipeline, staleness discovered by users, keys and bills multiplied. On KERNSTACK the index derives from the source records, so retrieval is as fresh as the data it searches.

Retrieval inside the project

A function embeds the question, asks the index for nearest neighbours, and then reads the winning records from their tables — applying permissions, stock, and pricing checks against live rows. That ordering (index proposes, record disposes) is what makes vector search safe to put in front of internal corpora and customer catalogues alike.

Model changes without migrations

Switching embedding models is an index operation over the same sources: declare, re-embed (tokens at the catalogue rate, computable in advance), compare against a fixed query set, and cut over. The corpus never moves house, so the evaluation compares models rather than migrations.

Hybrid search: declare a text index over the same sources and combine rankings in your function
Deleting a source record removes its passages — no orphaned vectors at another vendor
Custom endpoints can supply embeddings when a model you already run should

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call Vector search without external credentials:

Go SDK: github.com/coding-berlin/kernstack-sdk-go/sdk_search
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: Kernstack\Search

Implementation guides for Vector search

Python + Vector search →

Vector search in the Project Graph

Declarestack.jsonvector-search

RunVector searchintelligence

MeterOne credit balanceEU zone

stack.json — vector-search configuration plan · deploy

{
  "resources": {
    "search_indexes": [{ "name": "answers", "index_type": "vector",
      "sources": [{ "type": "tables", "name": "articles", "fields": ["title", "body"] }] }],
    "tables": [{ "name": "articles", "key_name": "article_id", "key_type": "S", "indexes": [] }]
  }
}

Metering · compute, storage, or network 1 Shared Balance

Storage is 0.04 credits per GB-hour. Egress is 9.00 credits per GiB. Compute beside the data is 0.01 credits per GiB-second.

Replaces: Amazon OpenSearch vector · Vectorize · no direct equivalent

FAQ

Frequently asked questions

What does embedding cost?

text-embed-v1 is 3 credits per 1,000 tokens — embedding 10 million tokens costs 30,000 credits, paid on ingest and change, not per query. Queries themselves spend ordinary function compute.

When should we still choose a dedicated vector database?

When retrieval is the product at extreme scale or needs specialised indexing a project-integrated index is not built for. Support corpora, catalogues, and document collections — the common ground — are served here without the sync tax.

Can results respect per-user permissions?

Yes, structurally: the index proposes candidates and your function checks each record against the caller before returning it. Private documents cannot leak through a shared ranking.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →