
Algolia introduces pay-as-you-go pricing for search - jlemoine
https://blog.algolia.com/introducing-algolias-most-customer-friendly-pricing
======
jhgg
Why the indirection in the pricing page. Like, if a unit is 1,000
searches/month, why not just put that in the matrix.

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.

~~~
alooPotato
We (Streak) are in the same boat. Looks like we'd be paying approx half a
million dollars a month on their new pricing which would be ~100x more than we
are paying now. Haven't heard from our enterprise rep but starting to get
nervous...

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.

~~~
jabo
Out of curiosity, could you expand on how it doesn't make sense for SaaS use
cases?

~~~
ysavir
Not the GP, but I figure their point is as follows:

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!

~~~
smnrchrds
Interesting. This reminds me of Canada Post's address complete API. You can
integrate it with your website or app to ensure the addresses the users enter
are valid within Canada and entered correctly. The pricing is around 5–10¢ per
search [0]. At that price point, it only makes sense to use it for e-commerce
if you are going to deliver physical goods to the customer and want to
minimize the number of returned "address not found" packages. But if the
pricing were lower, e.g. close to Google Map's 0.3¢ per search [1], I imagine
the list of potential uses would have increased substantially.

[0]
[https://www.canadapost.ca/pca/pricing/](https://www.canadapost.ca/pca/pricing/)

[1] [https://cloud.google.com/maps-
platform/pricing/sheet](https://cloud.google.com/maps-platform/pricing/sheet)

~~~
JMTQp8lwXL
Many local governments publish shapefiles (geojson) that have address
information. You could parse out addresses and have a fairly simple free
option. Since this data is based on property taxes, these data sets aren't
going to be missing parcels (or the tax collector would be missing potential
revenue).

~~~
smnrchrds
That still leaves out a lot: unincorporated lands, First Nation reserves,
small settlement where all the mail goes to a post office instead of
individual buildings, etc.

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.

~~~
JMTQp8lwXL
Yeah, my initial suggestion likely misses some corner cases. One case I am
fairly confident it covers is (not sure if correct term) mutual interest land
ownernship (aka, condos). Each layer has the same shape, but they're stacked
one top another; each layer is a billable portion of the interest (e.g., a
single condo on the shared land).

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.

------
jschumacher
Interesting change. Disclaimer, I joined one of Algolia's competitors
([http://sajari.com](http://sajari.com)) 6 months ago and we are about to
release a new product and change our pricing, so I've been thinking about this
a lot.

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.

~~~
rawoke083600
THIS ! I feel many times business put the "business-complexities" onto the
client, in this case the search-unit and although the CTO explained why (I
gloss over it) as a customer , I don't need to understand what makes it
difficult in your business nor do I want to know all your internal jargon and
limitations. I the customer understand searches and searches per month. Don't
make me think !

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.

~~~
andriosr
I prefer 1000x a complex pricing page than having to talk to a sales rep to
get the first sense of pricing.

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

------
AOsborn
This is a huge increase in pricing for all our customers using Algolia.

[https://web.archive.org/web/20200620142025/https://www.algol...](https://web.archive.org/web/20200620142025/https://www.algolia.com/pricing/)

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.

~~~
jlemoine
This is not the case, the price of unit decrease with volume and you can have
a big discount if you want to commit to a yearly (similar to AWS/GCP/Azure)

~~~
dubcanada
I fail to see where you provided him wrong, based on my math and the
calculator in the backend. The existing $29 is roughly equal to $240 on the
new plan 250,000 operations vs 250,000 searches. Obviously operations include
adding/updating/deleting data. But if you don't do any of that it's basically
a different of $220. If you do some operations, say half of them are
operations you are looking at $150~ vs $29.

------
atonse
We've loved algolia for the 2-3 sites we've used it for. The speed is
unbeatable.

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.

~~~
jlemoine
(I am the CTO and Co-founder), we are HIPAA compliant since 2020 and we can
support your use case

~~~
atonse
Good to know. We’ll be in touch!

------
kabes
So you basically only pay based on amount of queries? Dataset size doesn't
matter? We have an expensive elastic search setup. It's expensive because of
the amount of data it contains. But we don't run a lot of queries. So with
algolia this would basically be free and potentially faster?

~~~
gildas
It's written in small print under the screenshot of the "units widget" here
[1]:

"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."

[1] [https://www.algolia.com/pricing/](https://www.algolia.com/pricing/)

~~~
gberger
So for 1 million records, you need to spend $1k/month. Hmm.

~~~
beering
1 million records doesn't seem like all that much. If each document is 1 MB,
that's only 1 GB of indexed data. Does Algolia add a lot of value on top of
that?

~~~
PudgePacket
1 MB * 1,000,000 = 1 TB

------
iambateman
We just jumped on with algolia and we love it (4 days in)

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.

~~~
dvdhnt
For what it's worth, we do around ~5.1k queries on App Search and pay
something like $200.

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.

~~~
abri
How come you're paying $200 for 5.1k queries on App Search? 5k doesn't seem
like a big number so I imagine the lower tier plans/configs like the $20-30
plans should be enough right? Right now I have the lowest configuration and I
pay $25/month.

~~~
dvdhnt
Woah. Err I don't handle billing but it looks like we got App Search through
Elastic and it comes with the entire ELK stack behind it.

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.

------
AznHisoka
These guys are probably planning to IPO next year. And when they file the S1
they can claim they had 100% year over year growth (mostly due to price
increases).

~~~
jlemoine
(I am the CTO and Co-founder). I can reassure you this is not the case, I
don't have visibility on when we will do an IPO and we grandfather all
existing customers. We always did that and we still have customers today on
2013 pricing! It bring a lot of complexity internally.

We released this new pricing only because we are convinced this is better for
customers.

~~~
BrigadierG
I signed up for an account just to respond to this. I run a small, low-budget,
lean startup and we were banking on the starter plan lasting us at least 6
months as we gradually scaled. You cited in the blog post that making this
change was supposed to "reduce entry costs" but how has this happened?

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?

~~~
jlemoine
I understand your perception, pricing and perception is hard. I want to
reassure you that this is really way cheaper for people to start using the
product and as a company it was a huge project to lunch this pricing,
especially when you lower the price for such a large portion of users.

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.

------
ctx_
Everyone seems really hyped with Algolia, before and after the pricing update
but the major drawback i've seen is the pricing model that is still a big
issue IMO.

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.)"

------
grouseway
For comparison, the old free plan used to be 10k records plus 100k searches.
That would be $100/month now.

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.

~~~
karterk
I've been working on an open source alternative. It's dead simple to setup and
run (including raft based clustering). It also integrates seamlessly with
Instantsearch.js library. Would love to hear your feedback on Typesense:
[https://github.com/typesense/typesense](https://github.com/typesense/typesense)

~~~
grouseway
Tried it out with about 10k short docs and it works pretty well as a
potentional algolia replacement. I had to use 'sort_by' : '_text_match:desc'
to get good results.

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.

~~~
karterk
Thanks for the feedback. Synonyms is on the immediate roadmap, but not
available at the moment.

> 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.

------
disqard
As somebody with a small side-project that would benefit from search, this
sounds like a pretty good deal! Will have to give this a spin and see.

------
hitekker
Ah, “Value-based” pricing, or, how much a company can gouge their customers
before their customers change vendors.

------
JustARandomGuy
Love the change. I really like the "annual commitments" pricing - I love it
when I can pre-reserve a certain amount of performance and get a discount for
it.

------
hartator
Unit pricing seems complicated and arbitrary.

~~~
jschumacher
What is your preferred pricing model and why?

------
lbj
Well thats no good. I will say, that for the customers Ive had who have
suffered big problems with their search engines, Algolia has always been the
solution. It just works, so its worth paying for. Im a little concerned that
this change puts the price over the top.

------
sonic182
People, just use Doofinder ->
[https://www.doofinder.com/](https://www.doofinder.com/)

------
kumarski
While I love algolia, I hate the way it is implemented on producthunt.

------
cc_stoic
this is serverless search. I love it

~~~
winrid
For the user, correct, since you just plop a widget into a page client side.

------
wolco
A dollar for 1,000 queries. A million queries costs $10000 dollars?

For that money there are so many better options.

~~~
mitchbob
And those are?

~~~
zelly
Elastic Search

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.

~~~
mrweasel
For a quick search engine it's hard to beat Sphinx. I especially love that you
can just point it at a database and give it a query and it will just work.

------
julienreszka
This is awesome. Now that it exists seems like inevitable.

------
momokavar
Why do people want this product? If I use the demo search on their homepage,
theres several annoyances on mobile that made me nope out. Is it because
backend free form search queries are hard? or do people use this primarily for
the frontend quality? Edited for typo.

~~~
ponker
Because it gets customers to the product they want faster than anything else
in e-commerce. Selling shoes or something online? Algolia will earn back its
cost in conversion.

