Does query API support offset?


We’re using Pinecone vector DB and found it amazing!
However, we’ve got a problem using query API:
When we query for results, can we set the offset parameter of returned result list?

In our use case, we’d like to find the top_k = 1000 similarity results of a vector but we don’t want all the 1000 results included in one return; instead, we would like to fetch them in pagination(say 100 results per page, 10 pages), get 1-100 results in the first fetch, get 101-200 results in the second fetch. So we can have a quicker responsive UX without fetching unnecessary 201-1000 results in case user probably found the answer in the second fetch.

Could you please kindly suggest how we can do the “pagination” with the query API? Thanks.


Hi @LoveCactus,

We don’t support pagination or offsets today, but we are working on it. What some customers have done as a workaround is issue two or three queries at once; one with top_k of 10 that returns very fast, then top_k 100 and 1000. So by the time your end user is ready to page to item 11, the 100 items will have been returned; and by the time they’re looking at 101 the 1000 items have been returned.

It’s a little hacky admittedly, but it works as a sort of poor man’s pagination.

Thanks for the reply! Looking forward to the pagination support!

Could you please provide me with an update regarding the progress of this issue?

+1. Would be great to have.

I built an opensource tool for managing Pinecone (among other) vector databases. Since its opensource, here is the code.

TLDR; create a fixed ID and query + upsert the key into metadata. On n+1 queries filter out the fixed ID - now you can “walk” the entire database. It supports backoff from request errors as well as other edge cases in walking an entire DB.

Its not the perfect solution, but it does work :person_shrugging:

NOTE!!! The update for metadata update can sometimes be 30-120s until it is effective when on the starter tier. So you may need to sleep between loops for a while to ensure your “run id” is upserted and available on the subsequent query.