In Pinecone, what do the dimension and metric arguments to create_index lock in?

## What an index is In Pinecone an **index** is the top-level container you create, size and pay for. It holds records, each of which is an id, a dense vector of floating-point numbers, and optional metadata. Everything else — namespaces, queries, filters — happens inside an index. Creating one is a control-plane call on the client: The modern SDK is instantiated as `pc = Pinecone(api_key="...")` and the index is created with `pc.create_index(name="docs", dimension=1536, metric="cosine", spec=ServerlessSpec(cloud="aws", region="us-east-1"))`. Three of those arguments are structural and one is a label: the `name` identifies the index, `spec` chooses the deployment shape, and `dimension` plus `metric` fix the mathematics the index is built around. ## dimension An embedding model emits a vector of a fixed length — 384, 768, 1024, 1536, 3072 and so on depending on the model. `dimension` tells Pinecone that length, and it is enforced on every write. If the index says 1536 and you upsert a 768-float vector, the API rejects the request with a dimension-mismatch error. It does **not** pad with zeros, truncate, or project the vector; there is no coercion at all, because a vector of a different length is simply not a point in the same space and any distance computed against it would be meaningless. The practical consequence is that an index is bound to one embedding model family. This is the single most common beginner mistake in Pinecone: someone builds an index against one model, later swaps the model for a better one with a different output size, and discovers that the existing index cannot accept the new vectors at all. Even when two models happen to share a dimension the situation is not much better — the numbers are the same length but live in unrelated geometries, so mixing them in one index produces silently poor results rather than an error. The rule of thumb is: one index (or at least one namespace) per embedding model. ## metric `metric` selects the distance function: `"cosine"`, `"dotproduct"` or `"euclidean"`. Which of those suits a given embedding model is embedding theory, but two Pinecone-specific facts matter here. First, the metric is used both when the index structures data and when it scores a query, so it is not a per-query option — you cannot ask a cosine index for a Euclidean ranking. Second, the score in a query response is interpreted according to the metric: for `cosine` and `dotproduct` higher is more similar, for `euclidean` the value is a distance and lower is more similar. Code that sorts or thresholds on `score` without knowing the index's metric is a latent bug. ## Immutability and the migration pattern Neither `dimension` nor `metric` can be altered after creation. `pc.configure_index(...)` exists, but it changes operational settings — deletion protection, index tags, and for pod-based indexes the replica count or pod type — never the vector geometry. There is no ALTER INDEX equivalent. So a model change is a migration, and the standard shape is: 1. Create a second index with the new `dimension` and `metric`. 2. Re-embed the source documents with the new model and upsert into the new index. Pinecone does not store your original text unless you put it in metadata, which is one reason people keep the raw chunk text in metadata or in an external store of record. 3. Verify counts with `describe_index_stats()` and run offline relevance checks against the new index. 4. Flip the application's index name (usually a config value) and delete the old index once you are confident. Because the cutover is a config change, the usual approach is to keep the index name out of the code and in configuration or environment so the swap requires no redeploy of logic. ## Other creation-time choices Two more arguments deserve a mention. `spec` chooses `ServerlessSpec` (a cloud and region, with capacity managed for you) or `PodSpec` (an environment and explicit pod sizing) and cannot be converted in place either — moving between them is also a create-and-backfill migration. `deletion_protection="enabled"` can be set at creation or later via `configure_index`, and it blocks `delete_index` until it is turned off, which is a cheap guard for a production index that took hours to build. ## What interviewers are checking The question looks trivial but it separates people who have run Pinecone from people who have read the quickstart. The signal is: do you know the index is immutable in its two most important properties, do you know a dimension mismatch is a hard error rather than a silent coercion, and can you describe the re-embed-and-cut-over migration without hesitating.