4 ms·

Congrats to the team, it's been interesting to watch the development of Meilisearch (and it's close competitor Typesense). Algolia has really paved the way here

Congrats to the team, it's been interesting to watch the development of Meilisearch (and it's close competitor Typesense). Algolia has really paved the way here but it's nice to see the open-source options with more configurations and better default UX. There's also many search libraries if you want to embed search more deeply into your app. I have a list of modern search systems and libraries here: https://manigandham.com/post/search-systems-libraries https://manigandham.com/post/search-systems-libraries

naiv 4y ago
I will never understand who the target group of Algolia is besides a website where the number of records coincidentally is in the range of the number of queries. At least they got rid of the pricing per indexing transaction which made it even more absurd. If Algolia would offer an instance based pricing on cpu, ram and storage they would be the clear winner imho.
- manigandham 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
        50000 people per day is ‘large customer’ territory? That’s less than a request per second.
        maxFlow 4y ago
        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 4y ago
        let's think step by step: 24hrs * 60mins * 60secs = 86400 86400 < 50000 QED
        manigandham 4y ago
        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.
- luhn 4y ago
  A while back I priced out what Algolia would cost us and it ended up being thousands of dollars per month for something that was currently running a t3.micro Elasticsearch instance. Our usage was just worst-case when it came to their pricing dimensions: A large number of very small documents with a low search volume.

naiv 4y ago

I will never understand who the target group of Algolia is besides a website where the number of records coincidentally is in the range of the number of queries. At least they got rid of the pricing per indexing transaction which made it even more absurd. If Algolia would offer an instance based pricing on cpu, ram and storage they would be the clear winner imho.

manigandham 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      50000 people per day is ‘large customer’ territory? That’s less than a request per second.
      - maxFlow 4y ago
        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 4y ago
        let's think step by step: 24hrs * 60mins * 60secs = 86400 86400 < 50000 QED
      - manigandham 4y ago
        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.
luhn 4y ago
A while back I priced out what Algolia would cost us and it ended up being thousands of dollars per month for something that was currently running a t3.micro Elasticsearch instance. Our usage was just worst-case when it came to their pricing dimensions: A large number of very small documents with a low search volume.