Platform · Data

KERNSTACK Search

Search on KERNSTACK is a declared index, not a cluster: a search_indexes entry with index_type "text" over the tables and buckets that already hold your records (table sources name their fields; bucket sources can scope a prefix). Queries run in your functions against live source data, so results quote true prices, true stock, true permissions.

Full-Text Search

Talk to us Read Search Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Search

Teams otherwise run a standalone search cluster — nodes burning around the clock, a sync pipeline keeping it honest, a console nobody opens between incidents. On KERNSTACK the index derives from the source of truth and the cluster line item disappears.

Declaring an index

One index can combine several sources: the products table’s title and description, plus the manuals bucket under its published prefix. Because the index is built from those sources, a new product is findable when it exists and a deleted record leaves the results — the freshness properties that sync pipelines spend their lives approximating.

Text beside vector

Text search answers literal matching — names, SKUs, error codes, phrases. Its sibling, a vector index over the same sources, answers meaning. Most real search surfaces need both, and declaring both over one corpus is two entries in the same file rather than two vendors with two copies of your data.

Index storage bills at the storage rate (0.04 credits per GB-hour); queries spend function compute
Filters and permissions apply in your function against live rows after retrieval
Zero-result queries can be logged to a table — the search-quality agenda writes itself

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call 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

European alternatives to the hyperscaler equivalent

Amazon OpenSearch →

Implementation guides for Search

Go + Search →

Search in the Project Graph

Declarestack.jsonsearch

RunSearchinfrastructure

MeterOne credit balanceEU zone

stack.json — search configuration plan · deploy

{
  "resources": {
    "tables": [{ "name": "products", "key_name": "product_id", "key_type": "S", "indexes": [] }],
    "search_indexes": [{ "name": "catalog", "index_type": "text",
      "sources": [
        { "type": "tables", "name": "products", "fields": ["title", "description"] },
        { "type": "buckets", "name": "manuals", "prefix": "published/" }
      ] }]
  }
}

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 · no native equivalent · no direct equivalent

FAQ

Frequently asked questions

Do we have to keep the index in sync?

No. The index is declared over its sources and maintained from them. There is no exporter, webhook chain, or nightly job whose failure mode is silently stale search.

When is a dedicated search platform better?

At search-as-the-product scale: relevance engineering teams, extreme query volumes, specialised ranking pipelines. Catalogue, content, and internal search — the common cases — are an index declaration here.

Can one index span tables and buckets?

Yes. Sources mix freely: structured records from tables (with named fields) and documents from buckets (optionally prefix-scoped, size-capped). Results come back to your function, which authorises and enriches from live rows.

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 →