# Choosing serverless vs pods, and what the choice changes
## The short version
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.
## What differs in practice
1. **Creation spec.** Serverless: `ServerlessSpec(cloud="aws", region="us-east-1")` (Python) or `{ serverless: { cloud: "aws", region: "us-east-1" } }` (Node). Pods: `PodSpec(environment="us-east1-gcp", pod_type="p1.x1", replicas=1, shards=1)`. Pod environments are fixed strings like `us-east1-gcp`; serverless uses cloud plus region.
2. **Scaling.** Serverless scales automatically. Pods scale by changing replicas (query throughput) and shards (data sharding) or moving to a larger pod type; both are manual operations.
3. **Collections.** Pod indexes back up to collections; serverless indexes do not use collections the same way (use export or re-import for bulk moves).
4. **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.
5. **Latency profile.** Pods give consistent latency under load because the capacity is yours. Serverless is fine for bursty or moderate traffic.
## Rules for agents
1. Default to serverless for prototypes, RAG over documents, and anything with bursty traffic.
2. Consider pods only when you can state the sustained QPS and have measured that serverless throttles or costs more at that volume.
3. Never create a pod index "to try Pinecone". The pod-hour billing starts immediately.
4. When migrating pod to serverless, use the collection-based migration (see the migration workflow skill); there is no in-place conversion.
5. Record which type each index is in your runbook. `describe_index` returns the spec; check it before assuming scaling behavior.