Where Pinecone fits — and where teams hit the wall
Where Pinecone fits well: teams whose retrieval problem is genuinely large or specialised — very high vector counts, demanding latency targets — enough to deserve a dedicated managed vector database.
Where teams outgrow Pinecone: when the dedicated store means a second copy of the catalogue: embeddings generated in one pipeline, upserted to another vendor, and quietly going stale every time the source records change.
The sync problem that lives beside the database
A standalone vector store cannot see your data. So the architecture grows a pipeline: embed the records somewhere, upsert the vectors, remember to re-embed on every update and delete on every removal, and monitor the gap when the pipeline falls behind. The search results are only ever as true as that pipeline.
Around the pipeline accrete the usual costs of a second vendor: its own keys in your services, its own console in your incident channel, its own bill at the end of the month — for a component that, functionally, is an index.
An index, not another database
KERNSTACK treats vector search as what it is: an index. You declare a vector search index over the tables and buckets the application already writes, and the project keeps the index tied to that source of truth.
- Embeddings can come from the inference catalogue — text-embed-v1 at 3 credits per 1,000 tokens
- Text and vector indexes sit in the same stack.json as the functions that query them
- Deleting a record is a project operation, not a note to a sync pipeline at another vendor
Side-by-Side: Pinecone vs KERNSTACK
| Dimension | Pinecone | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Scope | A managed vector database, one component of a stack | A vector index declared inside the project that runs the app |
| Source of truth | Vectors copied and synchronised from your real data | The tables and buckets themselves; the index derives from them |
| Embeddings | Bring your own model and pipeline | Catalogue models such as text-embed-v1 at 3 credits per 1k tokens |
| Keys and vendors | A separate account, API keys, and console to operate | The project’s own resources; no second vendor in the request path |
| Bill | Pinecone, on top of the platform running your app | Part of the project’s single credit balance |
| Operator | A US vendor cloud, regions per their map | Our own bare metal in Europe, one zone per project |
Frequently asked questions
When retrieval is the product: extreme vector counts, specialised indexing needs, or latency budgets that a project-integrated index is not built for. A dedicated vector database earns its keep at that scale. Most product search never gets there, and pays the sync tax anyway.
The inference catalogue offers embedding and analysis models by name — text-embed-v1 at 3 credits per 1,000 tokens, sentiment-multilingual-v1 at 2 credits per 1,000 — called from your functions like any project resource. Vectors land in the declared index over your tables and buckets, metered from the same balance.
The durable asset is your source data, not the copied vectors. Records already live in your tables or files; on KERNSTACK they are indexed in place once the index is declared and the source is loaded. Teams typically re-embed from source rather than export vectors, which also clears out whatever staleness the old pipeline had accumulated.
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.