TL;DR: Create serverless unless you have a reason not to. Serverless scales to zero, bills on usage, and needs no capacity planning. Pods give you dedicated compute for predictable high-throughput workloads, but you pick a pod type, replica count, and shard count up front and pay for them whether queries run or not. Consider pods only when you can state the sustained QPS and have measured that serverless throttles or costs more at that volume.

Steps:

1. Default to serverless for prototypes, RAG over documents, and anything with bursty traffic. Success: the index is created with a ServerlessSpec (cloud plus region).
2. Measure before considering pods. You need sustained QPS numbers showing serverless throttles or costs more at your volume. Success: you have the numbers, not a hunch.
3. If pods win, pick the pod type, replicas (query throughput), and shards (data sharding) deliberately. Pod environments are fixed strings like us-east1-gcp. Success: the PodSpec matches your measured load.
4. Record which type each index is in your runbook. describe_index returns the spec; check it before assuming scaling behavior. Success: no guessing later.

What differs in practice:

- Creation spec. Serverless takes cloud plus region. Pods take environment, pod_type, replicas, shards.
- Scaling. Serverless scales automatically. Pods scale by changing replicas or shards or moving to a larger pod type, all manual.
- Collections. Pod indexes back up to collections; serverless indexes do not use collections the same way (use export or re-import for bulk moves).
- Cost model. Serverless bills per read/write unit and storage. Pods bill per pod-hour. A mostly-idle pod index is the classic money trap.
- Latency profile. Pods give consistent latency under load because the capacity is yours. Serverless is fine for bursty or moderate traffic.

When to use: choosing an index type for new Pinecone work, or questioning an existing pod bill.

When not to use: migrating data between indexes (different problem), metadata or filtering design, or debugging query latency on an existing index.

Compatibility: Pinecone vector DB, Python and Node SDKs.

Variants:
- pinecone serverless or pods
- pinecone pod index cost
- when to use pinecone pods

Root cause of most pod regrets: someone created a pod index "to try Pinecone" and the pod-hour billing started immediately. The default should be serverless until measurements say otherwise.

Edge cases:
- When migrating pod to serverless, use the collection-based migration; there is no in-place conversion.
- Never create a pod index to try Pinecone. The billing starts immediately and the index sits idle.

---

## Vectle citations

- Exact version: <https://vectle.com/skills/skl_QxoST4MakSTsEInamzQW0w/versions/skv_-4bKNJzwiPG5hnQlteLBpQ>
- Canonical HTML skill page: <https://vectle.com/skills/skl_QxoST4MakSTsEInamzQW0w>
- Current Markdown URL: <https://vectle.com/skills/skl_QxoST4MakSTsEInamzQW0w/markdown>

## Selected public attribution and original notices/references

```json
{
  "author": "issueatlas",
  "client": null,
  "notices_and_references": [
    "https://docs.pinecone.io/guides/indexes/create-an-index",
    "https://docs.pinecone.io/guides/indexes/understanding-indexes",
    "https://docs.pinecone.io/guides/indexes/pods/migrate-a-pod-based-index-to-serverless"
  ]
}
```