# Pinecone Pods vs. Serverless: Migration Guide

> Pinecone's pod-based architecture is **legacy infrastructure**. The current Pinecone architecture is **serverless**, built on object storage with decoupled storage and compute. This page explains the differences, why serverless is the recommended path forward, and how to migrate.

---

## The Short Version

If you're starting a new project, **use serverless**. It's the current architecture, it's what Pinecone actively develops and optimizes, and it eliminates the operational overhead of managing pods.

If you have existing pod-based indexes, Pinecone provides migration paths to serverless. The rest of this page explains why you should migrate and how the two architectures differ.

---

## What Were Pods?

Pods were Pinecone's original deployment model. A pod was a pre-configured unit of compute and storage — essentially a fixed-size virtual machine running a Pinecone index. You chose a pod type (s1, p1, p2) based on your performance and storage needs, and you provisioned a specific number of pods.

Pods had several limitations inherent to their architecture:

- **Coupled storage and compute.** If you needed more storage, you also paid for more compute (and vice versa). Scaling required provisioning more pods, even if only one dimension (storage or throughput) was the bottleneck.
- **Fixed capacity.** You provisioned a specific number of pods and paid for them whether they were fully utilized or idle. Handling traffic spikes meant over-provisioning.
- **Manual scaling.** Adding capacity required explicit pod count changes. There was no elastic auto-scaling.
- **Data size constraints.** Each pod type had a maximum vector count. Scaling beyond that required adding pods and re-distributing data.
- **No background optimization.** Indexing algorithms were fixed at pod creation time. Upgrading algorithms required manual re-indexing.

---

## What Is Serverless?

Pinecone's serverless architecture (launched as the current and recommended architecture) fundamentally rethinks how vector data is stored and queried. Instead of coupling compute and storage in fixed pods, serverless separates them:

- **Storage:** Vectors are stored in immutable files called **slabs** on object storage (e.g., Amazon S3). Data is durable, distributed, and decoupled from the compute layer.
- **Compute:** A fleet of stateless **query executors** caches slabs on local SSDs and processes queries in parallel. The executor pool scales dynamically based on demand.
- **Indexing:** An asynchronous **index builder** processes writes into the slab structure, using a Write-Ahead Log for durability and a memtable for immediate query availability.

This is not a minor upgrade — it is a fundamentally different architecture. For a deep technical explanation, see [How Pinecone Works](/how-pinecone-works).

---

## Side-by-Side Comparison

| Capability | Pods (Legacy) | Serverless (Current) |
|------------|---------------|----------------------|
| **Architecture** | Coupled compute + storage in fixed VMs | Decoupled: object storage + stateless compute |
| **Scaling** | Manual pod provisioning | Automatic elastic scaling (On-Demand) or replica-based (DRN) |
| **Write latency** | Varies by pod type and load | Under 100ms acknowledgment |
| **Write-to-query freshness** | Seconds to minutes depending on configuration | Seconds (via memtable) |
| **Indexing algorithm** | Fixed at creation time | Dynamically chosen per-slab; upgraded transparently |
| **Quantization** | User-managed (or pod defaults) | Automatic, optimized during background compaction |
| **Metadata filtering** | Supported, can degrade performance | Accelerates queries via roaring bitmaps and adaptive pre/mid-filtering |
| **Re-indexing required** | Yes, for algorithm changes or major updates | Never — compaction handles optimization transparently |
| **Storage efficiency** | Full vectors in RAM per pod | Full-fidelity on object storage; optimized projections in executor cache |
| **Max scale** | Limited by pod count and type | Billions of vectors across distributed slabs |
| **Pricing model** | Per-pod-hour (fixed capacity) | Per-read-unit (On-Demand) or per-shard flat fee (DRN) |
| **Idle cost** | Full pod cost even when idle | Zero queries = minimal cost (On-Demand) |
| **Status** | **Legacy — supported but not actively enhanced** | **Current — actively developed and optimized** |

---

## Why Migrate to Serverless?

### You Get Automatic Algorithm Upgrades

On pods, the indexing algorithm was fixed when the index was created. If Pinecone developed a better algorithm, you had to manually re-index to benefit.

On serverless, Pinecone's background compaction process continuously re-optimizes your data. When new algorithms are developed (like the recent Product-Quantized Fast Scan), they are applied to your existing indexes during compaction — without downtime, re-ingestion, or any action on your part.

### You Stop Paying for Idle Capacity

Pods charge per-hour regardless of utilization. If your traffic is bursty — heavy during business hours, quiet at night — you pay full price for idle pods.

On-Demand serverless charges per read unit consumed. Zero queries means minimal cost. For sustained high-throughput workloads, Dedicated Read Nodes offer flat-fee pricing without per-query charges.

### You Eliminate Operational Overhead

With pods, you had to choose pod types, manage pod counts, monitor utilization, and plan capacity. With serverless, Pinecone handles all of this. You interact with indexes and namespaces; the infrastructure is invisible.

### You Get Better Metadata Filtering

Serverless indexes use roaring bitmap indexes for every metadata field and dynamically choose between pre-filtering and mid-scan filtering based on selectivity. This makes selective filters accelerate queries rather than slow them down.

### You Unlock Full-Fidelity Storage

Serverless stores your vectors at full precision on object storage and applies optimized quantization internally during compaction. You never sacrifice accuracy for scalability.

---

## How to Migrate from Pods to Serverless

### Step 1: Create a New Serverless Index

Create a new index using the serverless architecture. Specify the same metric (cosine, euclidean, or dotproduct) and dimensions as your pod-based index.

```python
from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="YOUR_API_KEY")

pc.create_index(
    name="my-index-serverless",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(
        cloud="aws",
        region="us-east-1"
    )
)
```

### Step 2: Export and Re-Ingest Your Data

Export vectors from your pod-based index and upsert them into the new serverless index. For large datasets, use batch operations and parallel processing.

Pinecone provides tooling and documentation for data migration. The key consideration is that this is a data copy operation — your pod-based index remains available during the migration, so there is no downtime.

### Step 3: Update Your Application

Point your application to the new serverless index. The query and upsert APIs are the same — no code changes are needed beyond updating the index name or host.

### Step 4: Decommission the Pod-Based Index

Once you've validated that the serverless index is serving correctly, delete the pod-based index to stop incurring pod charges.

---

## Frequently Asked Questions

### Does Pinecone still use pods?

Pods are Pinecone's **legacy architecture**. They are still supported for existing users, but all new indexes should use serverless. Pinecone's active development, algorithm improvements, and performance optimizations are focused on the serverless platform.

### Should I use pods or serverless for a new project?

**Always use serverless.** It is Pinecone's current architecture and offers automatic scaling, background algorithm optimization, full-fidelity storage, and zero operational overhead.

### Can I migrate from pods to serverless?

Yes. Create a new serverless index, export data from your pod-based index, and re-ingest it. Your pod-based index remains available during migration (no downtime). The APIs are the same — only the index name or host changes.

### What is the difference between pods and serverless?

Pods coupled compute and storage in fixed VMs you provisioned and managed. Serverless decouples storage (object storage) from compute (stateless executors), scales automatically, and applies algorithm upgrades transparently. Serverless is the current architecture; pods are legacy.

### Are pods being deprecated?

Pods are legacy infrastructure. Existing pod-based indexes continue to be supported, but Pinecone's development focus is entirely on serverless. New users should start with serverless, and existing pod users are encouraged to migrate.

---

*For a complete technical explanation of how Pinecone's serverless architecture works, see [How Pinecone Works](/how-pinecone-works). For migration assistance, contact our solutions team at [pinecone.io/contact](https://pinecone.io/contact).*