The engineering bottleneck with assembled stacks
Keyword search fails the moment vocabulary diverges: the policy says “termination”, the employee searches “what happens if I quit”, and the result list is empty. Bolting on a hosted vector service fixes the ranking and creates a second problem — a copied corpus at another vendor, kept fresh by a sync job that nobody monitors until search results are embarrassingly old.
Architecture on the Software Lifecycle Cloud
You declare the index over its sources and the platform builds it from them. A function embeds the incoming query, asks the index for nearest neighbours, and merges results with ordinary keyed reads — price, permissions, stock — from the tables themselves. Text and vector indexes can coexist over the same sources when a query needs both exact terms and meaning.
One corpus, two ways in
Most real search is hybrid even when nobody calls it that: a part number must match literally, a symptom description must match semantically. Declaring a text index and a vector index over the same table lets one function combine both rankings, instead of forcing a choice between a search cluster for keywords and a vector vendor for meaning.
- New and edited records enter the index as source changes — no upsert pipeline to babysit
- Permission filtering happens in your function against the table record, so private documents never leak into a shared ranking
- Deleting a source record removes it from results; there is no orphaned vector at a second vendor
When keyword search is honestly enough
If users search for identifiers — order numbers, SKUs, error codes — a text index or even keyed reads are the right tool and embeddings are decoration. Semantic search earns its credits when the corpus is prose and the queries are phrased by people who did not write it. Many projects declare both and let the query decide.
Frequently asked questions
No pipeline in the vendor sense: the index is declared over tables and buckets, and embeddings come from text-embed-v1 at 3 credits per 1,000 tokens or from a custom endpoint you declare. Re-embedding after a model change is an index operation, not a data migration.
Yes, because retrieval runs through your function. The index proposes candidates; your code checks each record against the caller before returning it. That ordering — platform retrieves, your code authorises — is the only safe one for internal corpora.
Product-scale corpora: catalogues, policy libraries, documentation sets, support archives. If retrieval becomes an extreme-scale speciality workload, a dedicated vector database may fit better; the source data staying in your tables is what keeps that later move cheap.
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.