Trying to improve search UX without replacing algolia.
Our algolia usage spiked and the bill is painful because users keep submitting vague 1 word queries and constantly re-searching. so i was thinking to add an autocomplete layer in front of it that won't break the bank but still gives that instant intent driven…
Our algolia usage spiked and the bill is painful because users keep submitting vague 1 word queries and constantly re-searching. so i was thinking to add an autocomplete layer in front of it that won't break the bank but still gives that instant intent driven search feel. Obviously we could migrate everything to typesense or self-hosting meilisearch for standard search, but i do like certain things about algolias backend retrieval, if i can put an intent layer ai autocomplete on top to get better queries before they hit the API. Has anyone added an ai-autocomplete layer in front of algolia recently? did you actually migrate to a cheaper database alternative like typesense, or did you just add an intent layer on top of your existing search stack? trying to figure out what's easiest to maintain.
已收录讨论
Have you thought about caching certain search results? Or are they all different queries? Perhaps you can do some nudging to recommend certain searches so you can funnel them through that.
yeah caching helps with identical queries, but our biggest issue is that users type completely random, vague 1-word stuff that never repeats. nudging them toward structured queries via an autocomplete layer in the UI sounds interesting though, have you actually tried implementing a pre-search funnel like that without messing up the typing latency?
typesense is definitely cheaper, but swapping backends doesn't fix vague user inputs. whether it's algolia or typesense, if they just type jacket, they still get 500 unfiltered results and bounce. trying to fix query quality at the UI layer first before committing to tearing out our entire index.
thats how they get you lol. it took us like two hours to get it running perfectly on day one, and now it feels like a g*d*m hostage situation
Have you looked into bot protection?
Sounds like you need to be a better job ranking results. Adding boosts for popularity and engagement will help. https://typesense.org/docs/guide/ranking-and-relevance.html#text-match-score-type More mature systems execute an ML ranker on the top N candidates retrieved, but im guessing you’re not quite ready for that yet. If you need to increase recall, semantic search with vectors will help: https://typesense.org/docs/guide/semantic-search.html
yeah exactly that's the debate we're having rn. are you referring to magicx ai-autocomplete? commandbar looked way too bloated for our stack. so keeping algolia for retrieval while using an intent layer to structure the query first seems ideal
it's crazy because algolia is too expensive but easy af to set up initially. hence you get locked in
Unironically comparing it to drugs are we?
well if u just want cheap open source go with meilisearch. but if u want to keep algolia for retrieval and add an intent layer on top that actually structures queries before sending, give commandbar or ai-autocomplete a look. commandbar is kinda heavy for what it is tho.
You could use Typesense here. It already handles autocomplete, typo tolerance and filtering, and would probably be much cheaper than keeping Algolia plus adding another AI layer on top.
Where i used to work we always used algolia then switched to elastic because the algolia costs skyrocketed. Elastic was great. Not used it in a while though
Sounds like it is easier to just replace it with something else. I have seen Algolia, Bonsai and Elasticsearch and some others.
Recently I decided I wanted control of my own geo autocomplete. It could be fairly simple but it did need to handle 4 million + places around the world + fallback to address search. Elastic search is great but requires a lot of infrastructure and kind of felt like overkill. I ended up vibecoding it in Rust and it absolutely performs rock solidly. It builds the index at deploy time and is then just fully in memory. Very fast and perfect for this particular use and costs maybe $5 / month living fully isolated in its own Docker image. Of course I had to spend a while tuning it to my needs, but the end result is very satisfactory for my needs. I don't know how much data you are searching, but maybe you could do something similar to create that autocomplete layer to avoid the full text search.
Which platform is this on? If it's WordPress then Super Speedy Search is self-hosted and very good.
Would Algolia's query suggestions be an option? Query Suggestions
Switch to elasticsearch, or better yet, typesense. Both are much, much cheaper and can be tuned to have equivalent performance. ai autocomplete is too slow to handle search as you type queries, and will be more expensive in the long term. Search databases have solved this problem, just lock in and learn how to use them.
Searchcraft https://wordpress.org/plugins/searchcraft/
improving search UX without ripping out Algolia usually means owning the empty-state and the no-result path first. Ranking tweaks matter less than what you show when the query is almost right.
Worth asking how big the searchable set actually is before adding a layer on top. I run search over a couple hundred records by just shipping the whole index to the client as JSON and filtering in plain JS — no search service in the loop at all, no network round trip per keystroke, and the "UX" problems mostly evaporate because results are instant. That obviously breaks down somewhere in the thousands-of-records range, and it's useless if you need real relevance ranking or typo tolerance. But if you're mainly chasing autocomplete feel rather than genuine full-text relevance, the cheapest fix might be moving the small stuff client-side and leaving Algolia for the queries that actually need it.
It seems like the best move would be to overall haul everything to a cheaper tool. We use Typesense and I’m pretty sure during the demo call they said something about having an explicit pipeline for moving from Algolia that they help with.
Getting rid of algolia is right direction
Typeahead / predictive search works really well. I'm the developer of a competing product to Algolia, we ran a few tests and when we enabled typeahead it boosted click rates by an extra 1-2% overall. It's a great addition to add to your UX. I can't say whether it would be good for your Algolia set up but it worked great for our customers. Caching has also worked for us in terms of helping to maintain costs and load while improving latencies for users.
don’t need an AI intent layer for most of this, Algolia’s own guidance for this exact problem is simpler: debounce as-you-type search, firing a request on every keystroke is the single biggest source of runaway request counts, and adding a short delay so a query only fires after the user pauses can cut request volume dramatically without hurting the experience. that alone often kills a huge chunk of the bill from vague/re-searched queries, since most of that is just every keystroke firing its own billable request. second lever, straight from Algolia’s own cost guidance: cache common queries, popular repeated searches shouldn’t hit Algolia every single time, cache those results at the edge (Cloudflare/Vercel edge cache, even a simple Redis layer) so you’re not paying per-request for the same “sale” or “shoes” query thousands of times a day. if after debounce + caching you’re still seeing bad queries specifically (1-word, vague), that’s where a lightweight intent layer earns its keep, but keep it dumb and cheap: a small local model or even just a synonym/expansion dictionary that rewrites “shoe” → “running shoes size 9” style expansions before hitting Algolia, not a full AI service call per keystroke, that’d just trade one bill for another. full migration to Typesense/Meilisearch is the nuclear option, only worth it if debounce + caching + query rewriting still doesn’t get the bill under control. most teams solve this at the request-volume level before ever touching the backend, worth trying the cheap fixes first since they’re also the easiest to roll back if they don’t help.