Thanks for your feedback, we have some more work to make our pricing page clear. We need to add a simulator on this page.
The reason of this indirection is that we still have to deal with data/record. It is unfortunately not possible to pay only for searches, you can imagine a use case that push 100GB of data and perform only a few searches. The unit gives access to 1k searches request and 1k records. For the majority of users, they will pay per searches.
For SaaS use case, we have a different pricing where we price per GB with volume discount.
There is a volume discount, so the more units you consume, the cheaper they are. And if you commit to a year, the volume discount applies on your your yearly capacity. This give you a significant discount if you commit to a year. This is how you can have overages. Of course if you stay on a month-to-month play, there is no overages.
Would love to hear your feedback on Typesense: https://github.com/typesense/typesense
Good luck!
Sounds like the new pricing is for their ecommerce customers given how much value they provide them, doesn't seem to make sense anymore for SaaS use cases.
Btw, for your use case we designed a different pricing that we call OEM pricing that is simply based on the GB used and not the numbers of searches/records.
Also you can keep your existing plan, we force no-one to move to the new pricing.
> Finally, if you’re a current Algolia customer and are happy with your plan, that’s great! You can remain on your existing plan indefinitely.
If I'm running an e-commerce website, I don't mind pay-per-search since those searches may turn into sales, so the cost is justified. My income scales with search count, and the Algolia price is part of user acquisition costs.
If I'm running a SaaS business, the search is a feature for customers who have already paid, so I don't see any further returns from the search being used. The more a client uses search, the less I'm profiting from having them as a client. They could potentially even cost me money to service them!
Also, one of the main benefits from Canada Post API is that it gives you the canonical address Canada Post uses to deliver packages. I don't think this always overlaps with addresses municipalities use to assess taxes. For example, I can imagine for an apartment building belonging to a real estate management company, there would be a single entry in the municipality database (because there is only one owner who needs to pay taxes), but one entry per unit in Canada Post database.
A poor man's approach could be to query the publicly available data sets, and use that data when there's match. Then, only pay for queries that fall into the edge cases.
But search relevancy is only one part of the equation. Think about a physical store and how the milk is usually in the back and a few high margin items are close to the counter or strategically placed. The same can be true for an ecommerce store. If the search engine has the ability to take business metrics like revenue and margins, or customer data like loyalty programs or brand affinity into account, you can much better optimise for your desired business outcome.
We just recently switched one of the largest ecommerce retailers in Australia over from Algolia to Sajari by doing the above and increasing their conversion rate by 10%.
When we have a platform, it is very hard to have a pricing that works perfectly well for all industries and that is simple!
It’s a way better experience than having to talk to a sales rep to get a sense of pricing after 3 calls.
We face the same challenge with Decimlas.app, and will be adding pricing to the landing page in the next few weeks.
For anyone interested in creating a search at scale, I would recommend checking us out at appbase.io (founder here :wave:) - we provide relevant search, analytics, and access control for search and are built transparently on top of Elasticsearch. It also doesn't hurt that we author some of the most popular open-source search UI libraries: https://github.com/appbaseio/reactivesearch
I'd guess because they'd like to accurately model their compute requirements to try to get as low of a price as possible (e.g. via reserved EC2 instances).
If clients constantly and consistently shoot past what Algolia plans for, it might cause issues or at the very least cause the company to spend more on, on-demand instances than they intended to.
Free = 10,000 searches/month.
Standard = $1 per 1,000 searches. ...
Pay as you go:
1,000 - 10,000 searches = Free
11,000 - 100,000 searches = $1.00/ 1,000 searches
The whole to unit conversion really just adds a level of indirection that I don't understand. This was further confused by units having different colored dots depending on the plan, making me think there were 3 different kinds of units.
A slider would be nice, let me slide it to what my search volume for a given month would be, and tell me how much that would cost, factoring in volume discounts.
Additionally, this is a huge red flag:
> If you exceed your committed usage, there are overages that will be charged.
What are the overages??! Why is it not just sliding back to pay-as-you-go pricing, like reservations for say EC2 work.
----
As an aside, we use Algolia to power some search features at Discord. This new pricing structure looks to be an order of magnitude more expensive (we fall under the "contact sales" usage here...) Luckily we're grandfathered in or we'd have to consider putting a cloudflare worker in-front of this and leveraging that to do caching of common hot queries to reduce cost.