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

[jlemoine]

No worries, it will not be a 100x on the pricing. We will add a pricing calculator to simplify the projection.

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.

[timdorr]

They say you can keep your current pricing forever:

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

[chrysoprace]

Minor nitpick; indefinitely does not mean forever, it just means there's no defined end. It could end tomorrow, it could end in 10 years.

[Can_Not]

I don't know what the original prices are, but as someone who might like to use algoria search instead of MVP search, the idea that pricing scales with our usage (e.g. free tier -> lowest paid tier) is very appealing. There's too many SaaS where when your usage jumps plus 1kb suddenly they want $100/month instead of $0. Which is hard if you have a tight budget or wnat to keep a tight reign on your budget.

[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/

[1] 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.

[JMTQp8lwXL]

Does an e-commerce site search really need anything more than fuzzy matching on item names? It pay not be perfect, but if it provides relevant results 90% of the time, you're paying a big premium for SaaS search that may only net you a small tail end of additional sales.

[jschumacher]

In particular for ecommerce sites it pays to invest in search. A large percentage of transactions is initiated by search queries. You are correct that fuzzy matching will likely get you decent results. However, finding the right product 90% of the time or 98% of the time makes a huge difference if you have a high volume of transactions. Synonyms and a better spelling model can massively improve your results and the resulting conversion.

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

[jlemoine]

I am the co-founder of Algolia, we have a dedicated pricing for the SaaS use cases that we call OEM pricing (in a few words pay per GB of usage).

When we have a platform, it is very hard to have a pricing that works perfectly well for all industries and that is simple!

[andriosr]

Agreed! I really appreciate Algolia trying to make it simple and transparent.

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.