Pinecone Patterns

Quick Guide: Use @pinecone-database/pinecone (v7.x) for serverless vector database operations. Target indexes by host (pc.index({ host })), not by name. Use namespaces for multi-tenant isolation (physically separate, cheaper queries). Batch upserts at 200 records (max 1,000 or 2 MB). Metadata is limited to 40 KB per record with flat key-value pairs only (no nested objects). Pinecone is eventually consistent -- vectors may not appear in queries immediately after upsert. Use describeIndexStats() to verify indexing progress. For hybrid search, use dotproduct metric with sparse+dense vectors in a single index.

<critical_requirements>

CRITICAL: Before Using This Skill

All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering, import type, named constants)

(You MUST target indexes by host URL, not by name -- pc.index({ host }) is the v7 API; pc.index('name') is deprecated)

(You MUST batch upserts to max 1,000 records or 2 MB per request -- exceeding either limit causes a 400 error)

(You MUST use flat key-value metadata only -- nested objects, null values, and keys starting with $ are rejected by Pinecone)

(You MUST handle eventual consistency -- vectors are not queryable immediately after upsert; use describeIndexStats() or retry logic for freshness-critical flows)

</critical_requirements>

Examples

• Core Patterns -- Client setup, index creation, upsert, query, fetch, update, delete
• Namespaces & Multi-Tenancy -- Namespace isolation, multi-tenant patterns, namespace management API
• Metadata Filtering -- Filter operators, compound filters, best practices
• Hybrid Search -- Sparse-dense vectors, hybrid index setup, alpha weighting
• Inference API -- Embedding generation, reranking, integrated inference indexes
• Batch Operations -- Chunked upserts, parallel ingestion, bulk import

Additional resources:

• reference.md -- API quick reference, filter operators, limits, decision frameworks, production checklist

Auto-detection: Pinecone, @pinecone-database/pinecone, createIndex, createIndexForModel, upsert, query, topK, includeMetadata, sparseValues, namespace, describeIndexStats, vector database, similarity search, embedding, cosine, dotproduct, euclidean, RAG retrieval, semantic search, pinecone-sparse-english, rerank, searchRecords, upsertRecords, fetchByMetadata

When to use:

• Semantic search over document embeddings (RAG retrieval)
• Similarity search for recommendations, deduplication, or classification
• Multi-tenant vector isolation using namespaces
• Hybrid semantic + keyword search using sparse-dense vectors
• Embedding generation and result reranking via Pinecone Inference API

Key patterns covered:

• Client setup and index management (serverless vs pod-based)
• Vector CRUD operations (upsert, query, fetch, update, delete)
• Metadata filtering with compound operators
• Namespace-based multi-tenancy
• Sparse-dense hybrid search
• Pinecone Inference API (embed, rerank)
• Batch ingestion with chunking and parallelism
• Integrated inference indexes (automatic embedding)

When NOT to use:

• Full-text search with complex boolean queries (use a dedicated search engine)
• Relational data with joins and transactions (use a relational database)
• Real-time streaming or pub/sub messaging (use a message broker)
• Storing large binary blobs or documents (use object storage; store only embeddings + metadata references)

Philosophy

Pinecone is a managed serverless vector database purpose-built for similarity search at scale. The core principle: store embeddings and metadata, query by vector similarity, filter by metadata.

Core principles:

1. Vectors in, results out -- Pinecone stores high-dimensional vectors and returns the most similar ones. It is not a general-purpose database. Structure your data as embeddings + metadata references.
2. Namespaces for isolation -- Use namespaces to physically separate tenant data. Queries scan only the target namespace, reducing cost and latency compared to metadata filtering across a shared namespace.
3. Metadata is for filtering, not storage -- Keep metadata small (40 KB limit) and flat. Store document content in your primary database; store only filterable attributes (category, date, tenant ID) as Pinecone metadata.
4. Batch for throughput -- Individual upserts are inefficient. Batch at 200 records for optimal throughput (max 1,000 or 2 MB per request).
5. Eventual consistency is normal -- Freshly upserted vectors may not appear in query results immediately. Design your application to tolerate brief staleness or poll describeIndexStats() before querying.

Core Patterns

Pattern 1: Client Initialization

Create a Pinecone client from an API key. See examples/core.md for full examples.

// Good Example
import { Pinecone } from "@pinecone-database/pinecone";

function createPineconeClient(): Pinecone {
  const apiKey = process.env.PINECONE_API_KEY;
  if (!apiKey) {
    throw new Error("PINECONE_API_KEY environment variable is required");
  }
  return new Pinecone({ apiKey });
}

export { createPineconeClient };

Why good: API key from environment variable, validation before construction, named export

// Bad Example
import { Pinecone } from "@pinecone-database/pinecone";
const pc = new Pinecone({ apiKey: "sk-abc123..." });
// Hardcoded key leaks in version control

Why bad: Hardcoded API key is a security risk, no validation

Pattern 2: Index Targeting (v7 API)

Always target an index by its host URL, not its name. See examples/core.md.

// Good Example -- target by host
const indexModel = await pc.createIndex({
  name: "products",
  dimension: EMBEDDING_DIMENSION,
  metric: "cosine",
  spec: { serverless: { cloud: "aws", region: "us-east-1" } },
});

const index = pc.index({ host: indexModel.host });

Why good: pc.index({ host }) is the v7 API, avoids an extra API call to resolve the name to a host

// Bad Example -- target by name (deprecated)
const index = pc.index("products");
// Triggers an extra describeIndex call to resolve the host URL

Why bad: Targeting by name requires an extra network call and is deprecated in v7

Pattern 3: Upsert with Metadata

Upsert vectors with flat metadata for filtering. See examples/core.md for typed metadata.

// Good Example
interface DocumentMetadata {
  title: string;
  category: string;
  createdAt: number; // Unix timestamp (numbers only, no Date objects)
}

const NAMESPACE = "articles";

await index.namespace(NAMESPACE).upsert({
  records: [
    {
      id: "doc-1",
      values: embedding, // number[] matching index dimension
      metadata: { title: "Guide", category: "tutorial", createdAt: 1710000000 },
    },
  ],
});

Why good: Typed metadata interface, flat key-value pairs, numeric timestamp (not Date), namespace isolation

Pattern 4: Query with Metadata Filter

Query for similar vectors with metadata filtering. See examples/metadata-filtering.md for all operators.

// Good Example
const TOP_K = 10;

const results = await index.namespace(NAMESPACE).query({
  vector: queryEmbedding,
  topK: TOP_K,
  includeMetadata: true,
  filter: {
    $and: [
      { category: { $eq: "tutorial" } },
      { createdAt: { $gte: 1700000000 } },
    ],
  },
});

for (const match of results.matches) {
  console.log(match.id, match.score, match.metadata);
}

Why good: Named constant for topK, structured filter wit