Pinecone

Overview

Pinecone is a managed vector database. You send it embeddings, which are lists of numbers that capture the meaning or pattern of an item, and it stores them and returns the closest matches to a query vector with low latency. The service runs in the cloud, so the team that uses it does not install, patch, shard or scale database servers. It is a popular choice for production semantic search and for retrieval-augmented generation, where a language model needs relevant passages fetched on demand.

Because Pinecone is a service rather than a library, its main appeal is less operational work. You create an index, upsert vectors with optional metadata, and query with a vector and a filter. Behind the scenes the service handles indexing, replication and capacity. The trade-off is that you depend on a hosted provider and its limits, which is why open-source options such as Milvus, Weaviate, Qdrant and ChromaDB are often compared with it. For tabular data, Pinecone can act as the memory behind a model that turns rows into vectors, supporting row retrieval, duplicate detection and anomaly scoring.

What it is

A search engine for meaning

A normal database finds exact matches. A vector database finds near matches. Imagine a music shop where records are not sorted by title but by mood. If a customer holds up one record and says "more like this", the clerk walks to the same shelf and picks the nearest records. Pinecone is that clerk, working across millions of records at once, and the "mood" of each item is its embedding.

The pieces you work with

• An index is the top-level container. It has a fixed vector dimension and a similarity metric such as cosine, dot product or Euclidean distance.
• A record holds an identifier, a vector and optional metadata, which is a set of key and value pairs.
• A namespace is a partition inside an index. Queries target one namespace, which makes it a natural way to separate tenants, datasets or environments.
• Metadata filters restrict a search to records whose metadata match a condition, such as a category or a date range.
• Sparse vectors, used for keyword-style signals, can be stored alongside dense vectors for hybrid retrieval.

Managed service models

Pinecone has offered more than one way to run an index. Older designs let you pick pod types and sizes, so you reserved capacity. Newer designs are serverless, where storage and compute scale with use and you do not choose hardware. The exact options, limits and names change over time, so check the current documentation before planning capacity. The core API ideas stay stable: upsert, query, fetch, update and delete.

What it is not

Pinecone does not create embeddings for your own data unless you use an inference feature that the provider offers separately. You normally bring vectors from an encoder. It is not a transactional database, it does not support joins, and it is not a data warehouse. It is also not open source, so you cannot self-host the same engine. If you need to run in your own environment, consider an open-source alternative.

Where it came from

Vectors move from research to products

Machine learning in the 2010s turned text, images and audio into dense vectors. Finding nearby vectors is called nearest-neighbour search, and exact search becomes slow as collections grow. Research produced approximate methods such as graph-based indexes like HNSW and compression methods like product quantization, covered in IVF-PQ. Libraries such as FAISS made these methods available to engineers.

From library to service

Libraries leave many jobs to the user: storing data durably, serving requests, keeping indexes fresh, replicating for uptime and handling updates. Pinecone was created to offer these as a hosted service, so that application teams could treat vector search as an API. Its growth followed the wave of interest in semantic search and in retrieval for language model applications, when many teams suddenly needed a vector store in production.

Ideas it builds on

Like other vector databases, it builds on public ideas:

• Approximate nearest-neighbour indexes that trade a little accuracy for large speed gains.
• Metadata filtering combined with vector search.
• Hybrid retrieval that mixes dense meaning signals with sparse keyword signals, related to BM25 and hybrid search.
• Storage designs that separate durable storage from compute so capacity can scale.

For the research background that these methods come from, see /model/research. Exact internals of the hosted service are not fully public, so this article describes behaviour from the public API rather than guessing at implementation.

How it works

Step 1: choose a dimension and a metric

An embedding model produces vectors of a fixed length. The index must be created with the same length. The metric decides what "close" means. Cosine similarity compares direction and ignores length. Dot product rewards both direction and magnitude. Euclidean distance measures straight-line gap.

Analogy: two arrows on a map. Cosine asks whether they point the same way. Euclidean asks how far apart their tips are.

Step 2: create the index

You create an index by name with a dimension, a metric and a deployment specification. The service provisions what it needs and returns a host address for data operations. Creating an index is a one-off step, normally done by infrastructure code rather than by the application at start-up.

Step 3: upsert vectors with metadata

"Upsert" means insert or replace by id. You send batches of records, each with an id, a vector and metadata. The service stores them and makes them searchable after a short delay. This delay is why newly written data is eventually visible rather than instantly visible, so design tests with that in mind.

Step 4: query

A query sends a vector, a number of results to return, an optional metadata filter and an optional namespace. The service searches its internal index and returns the top matches with similarity scores, plus metadata if requested. The search is approximate, which means it may miss a true neighbour in exchange for speed.

Step 5: filter

Metadata filters let you say "closest items, but only where region is north and year is at least 2024". Filtering is applied inside the search so that the returned list is full of valid results, not trimmed afterwards. This is similar to asking the music clerk for the nearest records, but only from the jazz section.

Step 6: update and delete

You can update metadata, replace a vector, or delete records by id or by filter within a namespace. Deleting by filter is useful for data retention rules. Remember that large mutations can take time to be reflected everywhere.

Step 7: scale and operate

The service scales storage and queries according to the deployment model you chose. You monitor usage, latency and errors from the provider's console or API. You still own data quality: choosing a good encoder, good chunking and good metadata.

Hybrid retrieval in plain words

Dense vectors capture meaning but can miss exact tokens such as product codes. Sparse vectors capture exact terms. Hybrid retrieval stores both and combines the scores, often with a weight between them. If a query is a vague idea, lean on dense. If a query is a part number, lean on sparse.

Reranking

A first stage returns, say, fifty candidates fast. A second stage, such as a cross-encoder, reads the query and each candidate together and reorders them more carefully. This is described in cross-encoder reranking. Pinecone usually provides the first stage, while rerankers run separately or through an optional service.

Key concepts and terms

A worked example

Scenario

We have a small table of support cases. Each row has a text summary, a product line and a year. We want to find similar past cases for a new one, but only within the same product line.

Code

The sketch uses the Python client. Treat names as illustrative, because client signatures change between versions. The host and key are placeholders.

import os
from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])

index_name = "support-cases"
if index_name not in [i["name"] for i in pc.list_indexes()]:
    pc.create_index(
        name=index_name,
        dimension=384,
        metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="us-east-1"),
    )

index = pc.Index(index_name)

rows = [
    {"id": "case-1", "vec": embed("printer jams on startup"),
     "meta": {"product": "printer", "year": 2023}},
    {"id": "case-2", "vec": embed("paper tray not detected"),
     "meta": {"product": "printer", "year": 2024}},
    {"id": "case-3", "vec": embed("screen flickers after update"),
     "meta": {"product": "monitor", "year": 2024}},
]

index.upsert(
    vectors=[(r["id"], r["vec"], r["meta"]) for r in rows],
    namespace="cases-v1",
)

result = index.query(
    vector=embed("printer will not feed paper"),
    top_k=2,
    filter={"product": {"$eq": "printer"}},
    include_metadata=True,
    namespace="cases-v1",
)

for match in result["matches"]:
    print(match["id"], round(match["score"], 3), match["metadata"])

Here embed is your own function that calls an encoder producing 384-number vectors.

What happens

1. The index is created once with dimension 384 and cosine similarity.
2. Three records are upserted into the namespace cases-v1.
3. The query vector for "printer will not feed paper" is compared with stored vectors. The filter removes the monitor record.
4. The two printer cases are returned, with the paper-tray case likely ranked first because its meaning is closest.

A tiny numeric sketch of cosine

Take two-dimensional vectors for illustration. Query q = (1, 0). Record a = (0.9, 0.1). Record b = (0, 1).

• Cosine of q and a is about 0.99, so a is very close.
• Cosine of q and b is 0, so b is unrelated.

Real vectors have hundreds of dimensions, but the logic is identical.

Reading the scores

Scores are only comparable within one index and metric. A score of 0.8 does not mean 80 percent correct. Pick a cut-off by looking at real examples of good and bad matches, and consider dropping results below it rather than always returning k items.

Building the evaluation habit

Create a small set of queries with known good answers. After every change of encoder, chunking or filter, measure whether the right record appears in the top three or top ten. This simple hit-rate check catches most retrieval regressions, and it works well with tools such as DeepEval or Ragas for the generation step.

Strengths and limitations

Strengths

• Little operational work. No servers to run, patch or resize in the usual sense.
• A simple API with a small number of verbs.
• Low-latency search designed for interactive applications.
• Namespaces for clean multi-tenant separation.
• Metadata filtering inside the search.
• Support for sparse and dense vectors for hybrid retrieval.
• Scaling handled by the provider.
• Good client libraries and wide ecosystem support in frameworks such as LlamaIndex.

Limitations

• It is a hosted, closed-source service. You cannot inspect or self-host the engine, and you depend on the provider for availability and policy.
• Data leaves your network unless a private connectivity option fits your needs, which matters for regulated data.
• Costs depend on usage and are managed by the provider, so budget carefully and read current terms yourself.
• Query features are narrower than in a general database. There are no joins and no arbitrary SQL.
• Approximate search means recall below one hundred percent.
• Eventual consistency can surprise tests that read immediately after writing.
• Limits on record size, metadata size and batch size apply, and they can change.
• Changing the embedding model means re-embedding and re-uploading the data.

When the limits bite

A team that stores sensitive rows in the cloud may be blocked by data residency rules. A team with a billion small vectors may find a self-managed distributed engine easier to tune. A team that wants exact SQL filters over many columns may prefer pgvector inside PostgreSQL. In each case the lesson is to match the tool to the constraint, not to follow fashion.

How it compares with alternatives

A simple decision path

• Small team, no appetite for running infrastructure, data may live in the cloud: a managed service such as Pinecone fits.
• Must run inside your own network, or must avoid vendor dependence: pick an open-source engine.
• Already using PostgreSQL and the data is modest: try pgvector first.
• Just experimenting on a laptop: ChromaDB or FAISS is enough.
• Need keyword search and vectors with strong text features: consider Weaviate or Elasticsearch.

What to compare in a trial

Run the same data and the same queries through two candidates. Measure recall against exact search, latency at your expected concurrency, filter behaviour, ingestion speed, operational effort and, with the help of your finance team, expected cost. A one-week trial answers more than a long feature comparison.

Role in tabular foundation models

The link in one sentence

Tabular foundation models learn from raw tables, and a vector database such as Pinecone can serve as the searchable memory that sits beside them, storing row or column embeddings and returning similar ones on request.

What tabular foundation models do

These models read rows and columns directly. They handle mixed types such as numbers, categories, dates and text. They tolerate missing values. Many can work without meaningful column names, because they learn from patterns in the values and the relationships between columns. They are often pre-trained on very large numbers of synthetic tables, sometimes together with real tables, so they learn general rules of prediction. At use time they perform in-context learning: you supply labelled rows as context and they predict for new rows without updating weights. See /model/architecture and TabPFN for details of that approach.

Rows as vectors

Many tabular models produce an internal representation for each row. If you export that representation, you have a row embedding. Store the embeddings in Pinecone with the row id and useful metadata such as table name, time and label. Then similarity search answers "which stored rows look like this row", across tables far too large to place in a single model context.

Retrieval for in-context learning

In-context learning has a size limit: only so many rows fit in the context. When your training table has millions of rows, you can retrieve the nearest labelled rows for each query row and use only those as context. This is like asking a doctor to review the most similar past patients rather than the whole hospital archive. Pinecone handles the retrieval step with a metadata filter, for example restricting to the same segment or time window, and the tabular model handles the prediction step.

Mixed types and missing values

Embeddings do not remove the need for good preparation. A row with missing cells needs a consistent treatment before it is encoded, or the vector will reflect the gap instead of the content. Because the vector database only sees numbers, any weakness in the encoder carries straight through to retrieval. Store a flag in metadata for rows with heavy missingness so that you can filter or down-weight them.

Imputation

To fill a missing value, find rows similar to the incomplete row using the columns that are present, then borrow or average the target column from those neighbours. A vector search makes the neighbour step quick. The imputed value should still be checked against masked-ground-truth error, not accepted blindly.

Anomaly detection

A row that sits far from every stored neighbour is a candidate anomaly. Query the nearest neighbours, look at the distance to the k-th neighbour, and flag rows whose distance is unusually large. This gives a simple, explainable score. Cluster-level checks and model-based scores can be added on top.

Sector and semantic classification

When rows or columns are described by text, such as company descriptions or column headings, an embedding can place them near similar items. Labelled examples with known sectors or semantic types are stored as vectors. A new item is classified by looking at the labels of its nearest neighbours, a pattern called nearest-neighbour voting. A tabular foundation model can refine the decision using the numeric fields.

Continual learning without retraining

New labelled rows can be upserted at any time, and the next query can already use them. This is a light form of continual learning for the retrieval layer: knowledge grows without changing model weights. It does not replace true model updates, but it helps a system stay current between them. Remember to version embeddings, because mixing vectors from different encoder versions in one index damages results.

Honest limits of this role

Pinecone does not understand tables. It only compares vectors. The quality of everything above depends on the encoder, on consistent preprocessing and on honest measurement of recall and downstream accuracy, as discussed in /model/benchmarks. Whether to send table-derived vectors to a hosted service is also a governance question, because embeddings can leak information about the original rows.

Practical guidance and best practices

Plan the data model first

Decide what one record represents: a document chunk, a row, a column, a customer. Decide which metadata you need for filtering, and keep it small and typed consistently. Put large payloads in an ordinary database and store only an id in the vector record.

Match dimension and metric to the encoder

Use the metric the encoder was trained with. Many text encoders are meant for cosine similarity. Using the wrong metric lowers quality quietly.

Use namespaces deliberately

Use one namespace per tenant, per environment or per embedding version. This makes deletion and rollback simple. Avoid creating enormous numbers of tiny namespaces without checking the current limits.

Batch your writes

Send upserts in batches of a sensible size, handle retries with idempotent ids, and respect rate limits. A script that sends one record per request will be slow and costly.

Measure recall with a ground-truth set

Build a labelled query set. For each query note the records that should appear. Report hit rate at three, five and ten. Re-run after any change.

Tune top-k and cut-offs

More results give more context but more noise and more downstream cost. Start with a small k, add reranking if needed, and drop results below a score cut-off.

Keep embeddings and source in sync

If a source record changes, update or delete its vector. Store a content hash in metadata so a sync job can find stale vectors. Without this, your search slowly returns outdated rows.

Version the encoder

Write the encoder name and version into metadata or into the index name. When you change encoders, build a new index or namespace, re-embed, compare quality, then switch traffic.

Secure the integration

Keep the API key in a secrets manager, never in code. Restrict who can delete indexes. Use private networking if offered and required. Treat embeddings of sensitive rows as sensitive data.

Add monitoring

Track query latency, error rates, empty-result rates and the share of results below your score cut-off. A rising empty-result rate usually means a data or filter problem.

Plan for exit

Keep the raw data and the embedding code so you can rebuild the index elsewhere. Avoid code that depends on provider-specific behaviour where a thin wrapper would do.

Test with an eye on eventual consistency

When a test writes a record and immediately queries for it, allow a short wait or retry. Do not assume read-after-write.

Sizing an index on paper

You can estimate raw vector storage before you build anything. The raw size is roughly the number of vectors times the dimension times the bytes per number. With 32-bit floats each number takes four bytes.

These figures cover only the vectors. Metadata, index structures and replication add more, and the hosted service has its own accounting, so treat the table as a sanity check and not as a quote. The lesson is that dimension matters as much as row count. Halving the dimension halves the raw size, which is one reason smaller encoders are attractive.

Designing metadata for filters

Metadata is cheap to add and painful to change later. A few rules help.

• Use stable keys and consistent types. A field that is a number in one record and a string in another will break filters.
• Store low-cardinality fields that you will filter on, such as category, tenant, source and year.
• Store a source id that points back to the original row or document.
• Store a content hash and an encoder version for maintenance jobs.
• Keep each record's metadata small. Large blobs belong in a normal database.

Example record for a table row:

{
  "id": "orders:2025:000123",
  "values": [0.012, -0.044, 0.31],
  "metadata": {
    "table": "orders",
    "segment": "retail",
    "year": 2025,
    "label": "late",
    "missing_ratio": 0.12,
    "encoder": "row-encoder-v2"
  }
}

The vector is shortened here for display. A real vector has hundreds of values.

An end-to-end retrieval flow for a table question

Suppose a user asks, "Which past orders looked like this one and were late?" A typical flow looks like this.

1. Encode the new order row into a vector with the row encoder.
2. Query the index with the vector, a top-k of twenty and a filter such as label equals late.
3. Fetch the full rows for the returned ids from the primary database.
4. Optionally rerank the twenty rows with a more careful model.
5. Pass the best five rows to a tabular model as labelled context, or to a language model for an explanation.
6. Log the query, the ids returned and the final answer for later evaluation.

Each step can fail independently, so measure each one. If step two returns poor neighbours, no later step can fix it.

Operational checklist before going live

• Index created by infrastructure code, not by hand.
• Keys stored in a secrets manager and rotated on a schedule.
• Backups or a rebuild path: raw data, embedding code and encoder version recorded.
• Load test at the expected query rate, with realistic filters.
• Recall measured against exact search on a sample.
• Alerts for error rate, latency and empty results.
• A documented process to delete a person's data from vectors and metadata.
• A rollback plan for encoder changes using separate namespaces.
• A review of what the embeddings and metadata could reveal if exposed.

Debugging poor results

When results look wrong, work from the bottom up.

Cost-aware habits

Without quoting any price, a few habits reduce spending on any metered vector service. Delete vectors you no longer need. Avoid re-uploading unchanged records by comparing content hashes. Keep dimensions modest. Use filters and namespaces to limit the part of the index you search. Cache answers for repeated queries. Track the number of queries per feature, because a busy feature may need its own budget. For a wider view of planning, see cost and latency budgets.

Common mistakes

• Creating an index with the wrong dimension, then discovering it cannot be changed in place.
• Mixing vectors from two different encoders in one namespace.
• Using a metric that does not match the encoder.
• Storing large documents in metadata instead of an id that points to them.
• Treating similarity scores as probabilities.
• Never measuring recall, then blaming the language model for bad answers.
• Skipping metadata design and later being unable to filter.
• Forgetting to delete vectors when source records are removed.
• Hard-coding keys in notebooks that are later shared.
• Sending single-record upserts in a loop.
• Setting top-k very high and flooding the model context with noise.
• Assuming that a managed service removes the need for data quality work.
• Embedding sensitive rows without a governance review.

Frequently asked questions

What is Pinecone used for?

Pinecone is used to store embeddings and find the most similar ones quickly. Typical uses are semantic search, retrieval for language model applications, recommendations, duplicate detection and similarity lookups over rows or documents. Teams choose it when they want a hosted service with little operational work.

Is Pinecone open source?

No. Pinecone is a proprietary managed service, although its client libraries are published for developers. If you need an engine you can run yourself, open-source alternatives such as Milvus, Weaviate, Qdrant and ChromaDB are common choices, and each has its own trade-offs.

How is a vector database different from a normal database?

A normal database retrieves records by exact values or ranges. A vector database retrieves records by closeness in a numeric space, returning the most similar items first. Many vector databases also store metadata and filter on it, but they usually do not offer joins or full transactional guarantees.

Does Pinecone create embeddings for me?

The core database stores and searches vectors that you provide. You normally produce vectors with an encoder model of your choice. The provider may also offer separate embedding or reranking features, so check the current documentation, but the database itself works with any vectors of the right dimension.

Can Pinecone store tabular data?

It can store embeddings of rows, columns or table summaries, along with metadata such as table name, time and labels. It does not store tables as relational data or run SQL. A common pattern keeps the full table in a warehouse or database and keeps only vectors and ids in Pinecone.

How accurate is the search?

Search is approximate, so it returns very close neighbours but may occasionally miss the true closest one. Accuracy is measured as recall against exact search. You can check it by comparing results with a brute-force search on a sample of your own data, and you should do this before relying on the system.

How do I support multiple customers in one index?

Use namespaces, one per customer, or use a metadata field that you always filter on. Namespaces give clean separation and easy deletion. Metadata filters are flexible but depend on every query including the filter, so build it into a shared query function to avoid mistakes.

What happens if I change my embedding model?

Vectors from different models are not comparable, and the dimension may differ. You need to re-embed your data and upload it into a new index or namespace, test quality there, and then switch traffic. Keep the old one until the new one is proven.

Can I do keyword search with Pinecone?

You can combine dense and sparse vectors to support hybrid retrieval, where exact terms and semantic meaning both influence ranking. For heavy text search features such as complex analyzers and faceting, a dedicated search engine may fit better, or you can use both systems together.

Is it safe to put sensitive data in a hosted vector database?

It depends on your policies and the provider's controls. Embeddings can reveal information about the source data, so treat them as sensitive. Review encryption, access control, network options and data residency, and consider anonymising or avoiding raw identifiers in metadata.

Glossary

• Approximate nearest neighbour: Search that trades a small amount of accuracy for speed.
• Chunk: A piece of a document or a group of cells that is embedded as one vector.
• Cosine similarity: A measure of the angle between two vectors.
• Dense vector: A vector of mostly non-zero numbers produced by a neural encoder.
• Dimension: The number of values in a vector.
• Embedding: A numeric representation of an item that captures similarity.
• Eventual consistency: A property where writes become visible after a short delay.
• Hybrid search: Retrieval that combines dense and sparse signals.
• Index: A container of vectors with a set dimension and metric.
• Metadata: Key and value pairs stored with a vector for filtering and display.
• Namespace: A partition inside an index.
• Recall: The fraction of true nearest neighbours that a search returns.
• Reranking: Reordering candidates with a more careful model.
• Serverless: A deployment model in which capacity follows use.
• Sparse vector: A vector with mostly zero entries, used for keyword-like signals.
• Top-k: The number of best matches returned.
• Upsert: Insert a record, or replace it if the id exists.

Summary

Pinecone is a managed vector database that stores embeddings with metadata and returns the nearest matches quickly, using indexes, namespaces, filters and optional sparse vectors for hybrid retrieval. Its strength is low operational burden for production search. Its limits are dependence on a hosted provider, approximate recall, eventual consistency and a narrower query model than a general database.

In the tabular setting it acts as the memory beside a tabular foundation model. Row embeddings can be stored and searched to retrieve context for in-context learning, to find neighbours for imputation, to score anomalies by distance and to classify items by nearest-neighbour voting, while new rows can be added without retraining. Success depends on encoder quality, consistent preprocessing, honest recall measurement and careful governance. For model background see /model/architecture, /model/research and /model/benchmarks.

Related

It belongs to Vector search in my stack, under LLMs, retrieval, and evaluation. Others in the same group: