Algolia introduces pay-as-you-go pricing for search(blog.algolia.com) |
Algolia introduces pay-as-you-go pricing for search(blog.algolia.com) |
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.
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.
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.
Having worked at Atlassian before, I understand how important simple pricing can be. My personal (and probably biased opinion) is that this is a move in the wrong direction. It appears simpler on the surface, but the concept of a unit and understanding all the disclaimers associated with it make the pricing more complicated than before. If I have to read the faq to understand what I'm getting, it's too complicated IMHO. Also, it seems other features, like analytics retention, crawler, have moved into add-ons, which requires you to contact sales to find out how much you'll pay.
More granular pricing does provide more flexibility, but it also reduces predictability, which can be important especially in small to mid-sized businesses. I'm curious to understand how people feel about "usage pricing" vs. "tiered pricing" where you know exactly what you are paying each month? Which ones do you prefer? We are still finalising our own pricing, any feedback would be very much welcome.
Like going to a restaurant: I don't want to know the whole nine yards story as to why you don't have lasagne today since one of the guys didn't show up for work and he was supposed to make the sauce and another guy was over his government allowed working hours. All this might be true and adequately explained why there is no lasagne, but now I need to also understand about employees, government working hours and and and. Just give me lasagne or not :) It's almost always a red-herring if you need to "explain" your pricing or use internal-company-jargon in your pricing-pages.
Each industry has different aspects of how much value they get from a product, the effort to try to encapsulate these aspects into a single pricing functions is much appreciated.
We face the same challenge with Decimals.app - should be adding pricing soon as well
https://web.archive.org/web/20200620142025/https://www.algol...
The previous Starter tier pricing was a lot cheaper. Most important point to note is that additional searches were closer to 10k/$1 vs the proposed 1000 (additional 100k operations: $10/month). Yes, these were 'operations' not searches' but the mapping between operations vs searches doesn't appear to be anywhere near 10-1.
I wish we could've used it for one of our HIPAA use cases (patient data). I could've rolled out powerful search for an internal site in a day, but instead I'm having to build in postgres full text search and looking longingly at them.
Not that its going to be as good as Algolia but it could be a whole lot better for many use cases specifically TF/IDF and BM25 scoring:
There are many open source alternatives to algolia too.
I am using meilli search - https://github.com/meilisearch/MeiliSearch atm. It works pretty well without taking huge resources.
Sonic is interesting too if you want something minimal - https://github.com/valeriansaliou/sonic
"Number of indexed records is capped at roughly 10% of annual search volume. See FAQ for more information."
The FAQ says:
"When using Annual Commitment pricing (minimum one year commitment and 1,200 units), each unit contains 1,000 searches x 12 = 12,000 searches during the year, and 100 x 12 = 1,200 maximum of records at any point in the year."
Trying to figure out if the new pricing model is going to skyrocket costs or not. FWIW we are on the old $29/mo plan for the moment.
But Algolia is incredible.
Looking at Algolia (which we didn't go with because it was too expensive), the cost would be about even right now ($1.50 premium * 6). However, that doesn't include the elastic or kibana instance we get at the moment.
Hopefully the cost doesn't grow too sharply.
It's basically a service that you can use so users can search objects in your database, a bit like Google but just for your website or application.
We released this new pricing only because we are convinced this is better for customers.
Just the limit of the old free plan would cost you more than the old starter plan! The limit of the old starter plan would cost like 7x as much now. Can you give a single use case under which the new pricing is cheaper for entry level customers?
I think the new plan makes sense if you're selling to sites with purchase intent, but for searching knowledgebases it seems like it's way too expensive -- the value per search just isn't there. Especially when using instant searching and counting each slightly debounced keystroke as a search.
I couldn't find a way to create synonyms, is this possible?
Is it also possible to control typo sensitivity like algolia? e.g. min chars for 1 typo, min chars for 2 typos.
The curation features looks handy, but I haven't tried it yet.
Install and config was a breeze which is appreciated.
I hope it takes off for you. Nice work.
We now only count search request and we did a simulation on our existing free plan base, offering 10 units cover all of them.
Btw, we keep offering more quota for opensource projects.
Given you have 10K documents, if you want to make a "sort by something" you have to create a replica with another ranking configuration.
So if you want 4 sort criteria, you'll be billed for 40K document even if you have only 10k at start.
I've looked in competitors like Swiftype and even them point out this issue in the pricing page :
"Index once, sort all you want (No need to replicate engines to sort or filter your data in different ways. Once your data is indexed, it can be filtered, faceted and sorted at will.)"
For that money there are so many better options.
On this example: - 1M queries per month $847 in full pay-as-you-go - 1M queries per month with yearly commitment cost $7200 per year ($600 per month)
Lucene
Sphinx
Solr
And thousands of other ones made by hobbyists, but those are the mature (as in since the 90s) ones. For instance Craiglist uses Sphinx.
Depending on your use case, a front-end search library would work too:
Elasticlunr JS-search Flexsearch Fuse
> Is it also possible to control typo sensitivity
You can control overall number of typose with ?num_typos=1 -- there is no way to define min chars for a specific typo. The engine does make some intelligent decisions to optimize. For example, for a 2 letter query it does not use a num_typos=2 even if that is specified.
Glad to hear about the setup. Will continue to improve.
The previous pricing was based on indexing operations + search operations. The new pricing is only based on search request and in a lot of situation N search operations = 1 search request (disjunctive faceting, federated search, etc.). At the end, for the big majority of free users (> 99%) they have as many or more search request in the 10 free units than in the old plan.
I made a simple Proof-of-concept of a PHP backend based on Redisearch compatible with the Instantsearch.js library.
You can take a look at it here : https://github.com/MKCG/algolia-on-redisearch/tree/master/ap...
With the Covid crisis we were no longer able to pay 3K per month for a basic search engine and now we are using a solution based on this on production (> 30M search/month).
I know they are moving App Search to some kind of Elastic Enterprise service, perhaps we're dealing with that instead?
We use the analytics, clicks, and suggestion API's - idk if those are included at the base level or not.
Actually Manticore Search (fork of Sphinx)
"If you exceed your committed usage, there are overages that will be charged."
2. What would be the discounted cost for 10M and 100M queries per month with yearly commitment?
2. 10M/month with yearly commitment = $46895/year 100M/month with yearly commitment = $165895/year
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!
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.
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.