[manigandham]

Why do the number of records and searches have to be similar? The current pricing is simple - you pay per "search unit" which scales in both dimensions.

The vast majority of small/medium customers would rather pay-as-you-go than maintain a fixed cost instance, and it allows Algolia to efficiently pack them into a multitenant architecture instead of wasting resource overhead.

[naiv]

If you eg index geonames, you have 4 mio. records but you might only have 50.000 queries a month. you pay $4,000 for minimal compute resources, 4GB of RAM and 3 gigabytes of storage space. Would be less but algolia requires you to create a replica for each sort option separately.

With 4 mio. records and 4 mio. queries I would pay the same. But then at least have 4 mio. queries.

The other way around, if we would just index all 200+ countries in the world and have autocomplete with a lot of visitors we would pay for eg 50.000 users per day typing in 3 letters again $4.000.

Same for us, we offer 350.000 movies with 2 mio. scenes. With Typesense or even Elasticsearch Cloud we would pay 5% of what we would pay Algolia.

[manigandham]

Your usage seems to be in the "large" customer category where provisioned capacity is a better deal. Algolia does have volume discounts if you talk to them, but yes the other alternatives might be a better fit.

[Aeolun]

50000 people per day is ‘large customer’ territory? That’s less than a request per second.

[manigandham]

You're missing the point. Their scale (in number of records and queries) is a better fit for provisioned capacity than pay-as-you-go in the context of billing.

The exact small/large label doesn't matter, nor does the requests-per-second.

[maxFlow]

Would you mind sharing your thought process to get from `daily_users` to `reqs_per_sec`? I'm playing with some estimations of `concurrent_users` for a basic website, and I'd be quite interested in the breakdown.

[swyx]

let's think step by step:

24hrs * 60mins * 60secs = 86400

86400 < 50000

QED