> One slight misinterpretation and wrong input and you'd get an estimate that's overstated by as much as 1,000x.
Does it also mean that in real world usage, one slight misinterpretation or misevaluation of your metrics and you're liable to 1000x more than you planned to ?
I totally see this as a reality of online billing systems. I've misconfigured GCP prototypes and ended with 100+ bills where I though it would be 2 or 3 at most and didn't care to watch for a few days.
But I'd understand a client bailing out when they realize slight changes to the sliders result in wild increases in the planned pricing. And removing the tool would sure help for registration, but not help the customer if they hit these kind of issues down the line.
> Does it also mean that in real world usage, one slight misinterpretation or misevaluation of your metrics and you're liable to 1000x more than you planned to?
Unlikely. You can see why in these two examples that really happened:
One user I spoke with said they assumed "queries per second" is calculated by (number of searches) x (top-k for each search), where "top-k" is the number of results they want back. I don't remember their top-k but let's say it's 10 -- so they were entering a value for "queries per second" that was 10x higher than it should be and they'd see an estimate around 10x higher than they'd really be charged.
Another user thought you get "number of vectors" by multiplying the number of embeddings by the embedding dimensionality (1,536 is a common one). So they were entering a value literally 1,536x higher than they should've. Their actual usage would be calculated (by Pinecone) correctly and not be that high.
Vector dimensionality is a basic concept for AI engineers and QPS is a basic metric for DB admins, but Pinecone sees lots of users who are either new to AI or new to managing DBs or both.
> where "top-k" is the number of results they want back.
Some systems will do that, so I get the confusion. I think the YouTube API for instance has a quota system that takes internal operations into account, so getting back 10 results in a query effectively weights 10+ credits.
I better understand the kind of issues you are facing, as these kind of subtilities are inherently hard to explain.
For better or worse, that's another advantage of starting with a small trial account and actually see how the operations are billed for typical operations.
This specific bit kinda gives pause though:
> One slight misinterpretation and wrong input and you'd get an estimate that's overstated by as much as 1,000x.
Does it also mean that in real world usage, one slight misinterpretation or misevaluation of your metrics and you're liable to 1000x more than you planned to ?
I totally see this as a reality of online billing systems. I've misconfigured GCP prototypes and ended with 100+ bills where I though it would be 2 or 3 at most and didn't care to watch for a few days.
But I'd understand a client bailing out when they realize slight changes to the sliders result in wild increases in the planned pricing. And removing the tool would sure help for registration, but not help the customer if they hit these kind of issues down the line.