Pinecone Vector Database: Features, Pricing, and Setup Guide

What Pinecone Offers

Pinecone provides a managed API for storing, indexing, and querying vector embeddings. You send vectors through their Python, JavaScript, Java, or Go SDK, and Pinecone handles storage, indexing, replication, scaling, and serving. There are no servers to provision, no indexes to tune, no backups to configure, and no operating system updates to apply.

The core operations are straightforward. Upsert stores or updates vectors with their metadata. Query searches for the nearest neighbors to a given vector with optional metadata filters. Delete removes vectors by ID or filter. Fetch retrieves specific vectors by ID. List enumerates vector IDs in a namespace. These five operations cover the entire API surface that most applications need.

Pinecone supports vectors up to 20,000 dimensions (the practical range for current embedding models is 384 to 3072), stores up to 40KB of metadata per vector, and provides namespaces for logical partitioning within an index. Namespaces let you isolate different tenants, data sources, or use cases within a single index without creating separate infrastructure.

Serverless vs Pod Architecture

Pinecone offers two deployment models, and choosing the right one is the most important decision after deciding to use Pinecone.

Serverless indexes are the default for new projects and the recommended starting point. With serverless, Pinecone dynamically allocates resources based on your actual usage. You pay per read unit, write unit, and GB stored, with no minimum commitment. The free tier provides enough capacity for development and small production workloads: 100,000 vectors, up to 100 writes per second, and sufficient read units for several thousand queries per day.

Serverless indexes scale automatically. If your query volume spikes from 1,000 to 100,000 queries per hour, Pinecone allocates more compute transparently. When traffic drops, costs drop proportionally. This makes serverless ideal for variable workloads, new applications where query volume is unpredictable, and any situation where you want to avoid capacity planning entirely.

The trade-off is latency and throughput. Serverless queries typically run 8 to 15ms, compared to 3 to 8ms for pod-based indexes, because the serverless architecture involves more internal routing. For most AI agent applications, this difference is negligible since the LLM call that follows the vector search takes 500 to 3000ms. Serverless also has write throughput limits of 100 writes per second on the free tier and up to 1,000 on paid plans, which constrains real-time data ingestion for high-volume applications.

Pod-based indexes are Pinecone's original architecture. You provision specific pod types (s1 for storage-optimized, p1 for performance-optimized, p2 for lowest latency) and pay a fixed hourly rate. Pod indexes provide dedicated resources with guaranteed performance, supporting up to 200 queries per second per pod with consistent sub-10ms latency.

Pod architecture makes sense when you need guaranteed latency SLAs, when query volume is consistently high enough that pay-per-query pricing exceeds the pod cost, or when you need the p2 pod type's sub-5ms latency for real-time applications. The starting cost is approximately $70 per month for a single s1 pod, which handles up to 1 million vectors.

Pricing in Detail

Pinecone's serverless pricing has three components. Read units cost approximately $8 per million. A typical query with top-10 results consumes 5 to 10 read units, making the effective cost $0.04 to $0.08 per 1,000 queries. Write units cost approximately $2 per million. Each upsert operation consumes 1 to 5 write units depending on vector dimensionality and metadata size. Storage costs $0.33 per GB per month.

For concrete monthly costs at different scales: 500,000 vectors with 5,000 queries per day stays within the free tier. 2 million vectors with 20,000 queries per day costs approximately $30 to $60 per month. 10 million vectors with 100,000 queries per day costs approximately $200 to $500 per month. 50 million vectors with 500,000 queries per day costs approximately $1,000 to $2,500 per month on serverless, or $500 to $1,200 on a properly sized pod configuration.

The hidden cost that surprises many teams is metadata storage. If you store the original text alongside each vector (a common practice for RAG systems), the metadata can consume more storage than the vectors themselves. A 1536-dimensional vector takes about 6KB. A 2,000-character text chunk takes about 2KB. But many teams store additional metadata like source URLs, timestamps, and tags, pushing per-record storage to 10 to 15KB. At 10 million records, this totals 100 to 150GB of storage, costing $33 to $50 per month just for metadata.

Setting Up Pinecone

Getting started requires a Pinecone account and an API key. The Python SDK is the most common integration path.

Install the SDK with pip install pinecone. Initialize the client with your API key. Create a serverless index by specifying a name, dimension (matching your embedding model's output dimension), metric (cosine, dotproduct, or euclidean), and cloud provider (aws or gcp) with a region.

Once the index is created, you connect to it, upsert vectors with their IDs and metadata, and query by passing a vector along with the number of results you want and any metadata filters. Results come back as a list of matches with scores, IDs, and metadata.

The entire setup from account creation to first query typically takes 15 to 30 minutes, which is Pinecone's primary selling point. No Docker containers, no infrastructure configuration, no scaling decisions.

Metadata Filtering

Pinecone supports metadata filters on queries using a JSON-based filter syntax. Supported operators include $eq (equals), $ne (not equals), $gt, $gte, $lt, $lte (numeric comparisons), $in and $nin (set membership), and $exists (field presence). Filters can be combined with $and and $or logical operators.

Example filters: find vectors where category equals "billing" and created_at is greater than a specific timestamp. Or find vectors where department is in the set ["engineering", "product"] and priority is not equal to "low".

Filtering performance depends on selectivity. When the filter matches a large portion of vectors (above 10%), performance is nearly identical to unfiltered queries. When the filter is very selective (matching under 1%), the system may not find enough matching candidates in its search space, resulting in fewer results than the requested top-k. This is a known limitation of the serverless architecture. Pod-based indexes handle selective filters better because they have dedicated compute for exhaustive scanning when needed.

Namespaces provide coarse-grained isolation without the overhead of filter evaluation. If your application serves multiple tenants, creating a namespace per tenant is more efficient than storing all vectors in one namespace and filtering by tenant_id. Each namespace has its own isolated vector space, which means queries never cross namespace boundaries.

Strengths

Zero operational burden. No servers, no upgrades, no capacity planning. This is genuinely valuable. Engineering hours spent maintaining infrastructure have a real cost that often exceeds the premium of a managed service.

Consistent reliability. Pinecone maintains a public status page with historical uptime above 99.95%. Their SLA guarantees 99.95% availability on paid plans. For production AI applications where vector search downtime means the agent cannot function, this reliability matters.

Ecosystem integration. Every major LLM framework, LangChain, LlamaIndex, Semantic Kernel, Haystack, Flowise, has first-class Pinecone integration. Most tutorials and example applications use Pinecone as the default vector database. This means more community examples, more Stack Overflow answers, and faster debugging when something goes wrong.

Serverless pricing for low volume. The free tier is genuinely useful for development and small production workloads. Pay-per-query pricing means you do not pay for idle capacity, which is ideal for applications with variable or unpredictable traffic.

Limitations

No self-hosting option. Your data lives on Pinecone's infrastructure. For organizations with strict data sovereignty requirements, HIPAA compliance obligations, or security policies that prohibit third-party data storage, this is a disqualifier. You cannot run Pinecone in your own cloud account or on-premises.

Higher latency than self-hosted alternatives. Every query crosses the network to Pinecone's servers and back. Self-hosted Qdrant on the same machine as your application delivers 2 to 3ms queries versus Pinecone's 8 to 15ms. For most applications this difference is irrelevant, but for latency-sensitive real-time systems, it matters.

Cost at scale. Pay-per-query pricing is efficient at low volumes but expensive at high volumes. At 1 million queries per day, Pinecone serverless costs approximately $1,200 to $2,400 per month. Self-hosted Qdrant handling the same workload costs $100 to $200 per month in cloud compute. The crossover point where self-hosting becomes cheaper is typically around 100,000 to 200,000 queries per day.

Write throughput limits. Serverless indexes limit write throughput to 100 upserts per second on the free tier and 1,000 on paid plans. Applications that need to ingest data in real time, like a support agent that must index new tickets immediately, may hit these limits. Pod-based indexes have higher write throughput but come with minimum monthly costs.

Limited query expressiveness. Pinecone's filter syntax covers basic conditions but lacks the expressiveness of SQL (no JOINs, no subqueries, no aggregations). If your vector search needs to combine with complex relational queries, you will end up maintaining both Pinecone and a relational database with the associated data synchronization complexity.

When to Choose Pinecone

Pinecone is the right choice when your team has limited or no infrastructure engineering capacity, when you want to ship a production vector search system this week rather than next month, when your query volume is moderate (under 200,000 queries per day), when you do not have data sovereignty requirements that prohibit managed services, and when you value reliability and ecosystem support over raw performance and cost efficiency.

Pinecone is the wrong choice when you need data to stay in your own infrastructure, when you are processing over 500,000 queries per day and cost is a priority, when you need sub-5ms query latency, or when your application requires complex queries that combine vector search with relational operations.