[HN Gopher] Meilisearch - search engine API bringing AI-powered ...
___________________________________________________________________
Meilisearch - search engine API bringing AI-powered hybrid search
Author : modinfo
Score : 113 points
Date : 2025-04-14 12:46 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| be_erik wrote:
| Is meilisearch ready for production workloads? I would love to
| use some of the feature set, but is the only option for HA
| running multiple instances and keeping them in sync?
| brunohaid wrote:
| You might want to look at https://typesense.org/ for that.
| tpayet wrote:
| Yup it is, Meilisearch Cloud offers 99.99% SLA :)
|
| We served billions of searches for hundreds of customers
| monthly
| Kerollmops wrote:
| Meilisearch has been production-ready since v1.0. I made it in
| Rust to ensure it stays production-ready for years and years.
| Memory-safe languages are here to replace unsafe ones like C++
| and reduce the number of breaches you expose in production.
|
| Here is an article by Google showing the benefits of using
| memory-safe languages in production rather than others. It is
| explicitly rotating around Rust [1].
|
| [1]: https://www.chromium.org/Home/chromium-security/memory-
| safet...
| sealeck wrote:
| Writing software in Rust doesn't necessarily mean that it
| works reliably for real-world workloads. Sure, Rust prevents
| you from doing lots of stupid things; it is very much in the
| class of "necessary but not sufficient condition" for writing
| software (of course, you can also use other languages, but
| memory safety should be table stakes for all software these
| days).
| arccy wrote:
| This reply doesn't inspire confidence at all...
|
| Made in Rust isn't a magic bullet to be production ready, and
| I'd be more concerned about logic bugs rather than CVEs.
|
| 1.0 is like the bare minimum to be used in production, but
| that doesn't necessarily mean it's been battle tested enough
| to be considered production ready.
| bigtones wrote:
| We use Meilisearch in production with a 7 million article
| corpus - it works really well.
| iambateman wrote:
| My understanding for Meilisearch is that you need enough RAM
| to keep everything in memory...but you're (probably) not
| keeping full-text in memory for millions of articles.
|
| Is it just searching metadata, or do you just have a setup
| that's beefy enough to support that level of memory?
|
| Or am I just wrong? :D
| tpayet wrote:
| Meilisearch keeps all the data on disk. It uses memory-
| mapping for optimizing performance, by default everything
| is safe on disk and the OS cache the most needed pages in
| memory.
|
| So it works on any machine, really. 2GiB is usually enough
| for most workloads, but the bigger the dataset, the faster
| it will be if you give it more memory!
| Hawxy wrote:
| Tested Meilisearch recently, was a great experience, getting a
| multi-index search running in our frontend was very easy. Just
| wish they had an Australian instance, the closest is Singapore :(
| tpayet wrote:
| Reach out to the sales or CS team, depending on your workload
| we could open that region pretty quickly :D
| jnovek wrote:
| I recently stood up the server in our k8s cluster and that part
| was also pretty easy, at least compared to elastic.
| captainkrtek wrote:
| I used Elasticsearch 10 years ago and wasn't a fan then, this
| last year decided to try Elastic Cloud and have been quite
| happy, a ton has matured over the years.
| drewnick wrote:
| I installed coolify on a VM (was featured here last week) and
| it had a one-click Meilisearch docker install. I sent 1,000,000
| records to it "just worked" on a little $8/mo Hetzner instance.
| bsnnkv wrote:
| Been a happy user of MS in production for https://notado.app for
| many years, and someone from MS even reached out to me a few
| years ago thanking me for my write-up of syncing Postgres records
| to MS[1], saying they used it as a reference for something they
| later shipped.
|
| I haven't kept up with the latest updates, all these new AI
| references don't inspire confidence at all, but the older version
| I'm running is chugging along and doing a great job.
|
| [1]: https://notado.substack.com/p/how-notado-syncs-data-from-
| pos...
| amelius wrote:
| If I may ask, how many searches per day over what volume of
| data?
| irevoire wrote:
| AI is completely opt-in. As long as you don't specify an
| embedder in the settings, you can continue using the engine as
| usual. There was no breaking change and the performances
| improved a lot in v1.12 so you might want to give it a try!
| esafak wrote:
| What's the hybrid reranking story? Does it support streaming
| ingestion and how?
| Kerollmops wrote:
| Meilisearch decided to use hybrid search and avoid fusion
| ranking. We plan to work on reranking soon, but as far as I
| know, our hybrid search is so good that nobody asked for
| reranking. You can read more about our Hybrid search in our
| blog post [1].
|
| About streaming ingestion support. Meilisearch support basic
| HTTP requests and is capable of batching task to index them
| faster. In v1.12 [2], we released our new indexer version that
| is much faster, leverages high usage of parallel processing,
| and reduces disk writes.
|
| [1]: https://www.meilisearch.com/blog/hybrid-search [2]:
| https://github.com/meilisearch/meilisearch/releases/tag/v1.1...
| adeptima wrote:
| Meilisearch is great, used it for a quick demo
|
| However if you need a full-text search similar to Apache Lucene,
| my go-to options are based on Tantivy
|
| Tantivy https://github.com/quickwit-oss/tantivy
|
| Asian language, BM25 scoring, Natural query language, JSON fields
| indexing support are all must-have features for me
|
| Quickwit - https://github.com/quickwit-oss/quickwit -
| https://quickwit.io/docs/get-started/quickstart
|
| ParadeDB - https://github.com/paradedb/paradedb
|
| I'm still looking for a systematic approach to make a hybrid
| search (combined full-text with embedding vectors).
|
| Any thoughts on up-to-date hybrid search experience are greatly
| appreciated
| jitl wrote:
| Quickwit was bought by Datadog, so I feel there's some risk
| quickwit-oss becomes unmaintained if Datadog's corporate
| priority shifts in the future, or OSS maintenance stops
| providing return on investment. Based on the Quickwit blog
| post, they are relicensing to Apache2 and releasing some
| enterprise features, so it seems very possible the original
| maintainers will move to other things, and it's unclear if
| enough community would coalesce to keep the project moving
| forward.
|
| https://quickwit.io/blog/quickwit-joins-datadog#the-journey-...
| iambateman wrote:
| I have an implementation of Quickwit, so I've thought about
| this.
|
| The latest version is stable and fast enough, that I think
| this won't be an issue for a while. It's the kind of thing
| that does what it needs to do, at least for me.
|
| But I totally agree that the project is at risk, given the
| acquisition.
| inertiatic wrote:
| >I'm still looking for a systematic approach to make a hybrid
| search (combined full-text with embedding vectors).
|
| Start off with ES or Vespa, probably. ES is not hard at all to
| get started with, IMO.
|
| Try RRF - see how far that gets you for your use case. If it's
| not where you want to be, time to get thinking about what
| you're trying to do. Maybe a score multiplication gets you
| where you want to be - you can do it in Vespa I think, but you
| have to hack around the inability to express exactly that in
| ES.
| Kerollmops wrote:
| > I'm still looking for a systematic approach to make a hybrid
| search (combined full-text with embedding vectors).
|
| You know that Meilisearch is the way to go, right? Tantivy,
| even though, I love the product, doesn't support vector search.
| Its Hybrid search is stunningly good. You can try it on our
| demo [1].
|
| [1]: https://wheretowatch.meilisearch.com/
| oulipo wrote:
| why couldn't it be possible to just embed
| Meilisearch/Tantivy/Quickwit inside Postgres as a plugin to
| simplify the setup?
| Kerollmops wrote:
| > [..] to simplify the setup?
|
| It would be simpler to keep Meilisearch and its key-value
| store out of Postgres' WAL and stuff and better propose a
| good SQL exporter (in the plan).
| kk3 wrote:
| As far as combining full-text search with embedding vectors
| goes, Typesense has been building features around that -
| https://typesense.org/docs/28.0/api/vector-search.html
|
| I haven't tried those features but I did try Meilisearch awhile
| back and I found Typesense to index much faster (which was a
| bottleneck for my particular use case) and also have many more
| features to control search/ranking. Although just to say, my
| use case was not typical for search and I'm sure Meilisearch
| has come a long way since then, so this is not to speak poorly
| of Meilisearch, just that Typesense is another great option.
| Kerollmops wrote:
| Meilisearch just improved the indexing speed and simplified
| the update path. We released v1.12 and highly improved
| indexing speed [1]. We improved the upgrade path with the
| dumpless upgrade feature [2].
|
| The main advantage of Meilisearch is that the content is
| written to disk. Rebooting an instance is instant, and that's
| quite useful when booting from a snapshot or upgrading to a
| smaller or larger machine. We think disk-first is a great
| approach as the user doesn't fear reindexing when restarting
| the program.
|
| That's where Meilisearch's dumpless upgrade is excellent: all
| the content you've previously indexed is still written to
| disk and slightly modified to be compatible with the latest
| engine version. This differs from Typesense, where upgrades
| necessitate reindexing the documents in memory. I don't know
| about embeddings. Do you have to query OpenAI again when
| upgrading? Meilisearch keeps the embeddings on disk to avoid
| costs and remove the indexing time.
|
| [1]: https://github.com/meilisearch/meilisearch/releases/tag/
| v1.1... [2]: https://github.com/meilisearch/meilisearch/relea
| ses/tag/v1.1...
| irevoire wrote:
| I hate the way typesense are doing their << hybrid search >>.
| It's called fusion search and the idea is that you have no
| idea of how well the semantic and full text search are being
| doing, so you're going to randomly mix them together without
| looking _at all_ at the results both searches are returning.
|
| I tried to explain them in an issue that in this state it was
| pretty much useless because you would always have one or the
| other search strategy that would give you awful results, but
| they basically said << some other engine are doing that as
| well so we won't try to improve it >> + a ton a justification
| instead of just admitting that this strategy is bad.
| jabo wrote:
| We generally tend to engage in in-depth conversations with
| our users.
|
| But in this case, when you opened the GitHub issue, we
| noticed that you're part of the Meilisearch team, so we
| didn't want to spend too much time explaining something in-
| depth to someone who was just doing competitive research,
| when we could have instead spent that time helping other
| Typesense users. Which is why the response to you might
| have seemed brief.
|
| For what it's worth, the approach used in Typesense is
| called Reciprocal Rank Fusion (RRF) and it's a well
| researched topic that has a bunch of academic papers
| published on it. So it's best to read those papers to
| understand the tradeoffs involved.
| irevoire wrote:
| > But in this case, when you opened the GitHub issue, we
| noticed that you're part of the Meilisearch team, so we
| didn't want to spend too much time explaining something
| in-depth to someone who was just doing competitive
| research, when we could have instead spent that time
| helping other Typesense users. Which is why the response
| to you might have seemed brief.
|
| Well, in this case I was just trying to be a normal user
| that want the best relevancy possible and couldn't find a
| solution. But the reason why I couldn't find it was not
| because you didn't want to spend more time on my case, it
| was because typesense provide no solution to this
| problem.
|
| > it's a well researched topic that has a bunch of
| academic papers published on it. So it's best to read
| those papers to understand the tradeoffs involved.
|
| Yeah, cool or in other word << it's bad, we know it and
| we can't help you, but it's the state of the art, you
| should instruct yourself >>. But guess what, meilisearch
| may need some fine-tuning around your model etc, but in
| the end it gives you the tool to make a proper hybrid
| search that knows the quality of the results before
| mixing them.
|
| If other people want to see the original issue:
| https://github.com/typesense/typesense/issues/1964
| spiderfarmer wrote:
| I think this is a good example of why people should
| disclose their background when commenting on competing
| products/projects. Even if the intentions were sound,
| which seems to be the case here, upfront disclosure would
| have given the conversation more weight and meaning.
| k4rli wrote:
| Librechat has it as a dependency. Seems very memory heavy like
| elasticsearch. 3G+ memory at all times even on a new-ish instance
| with just one user.
| tpayet wrote:
| Actually, Meilisearch uses the RAM available by design because
| it uses LMDB (which is memory-mapped) under the hood for key-
| value storage.
|
| It's a feature, not a bug :D
|
| The cool thing about that is that it is the OS that will get to
| choose which process to allocate memory, and you can always run
| it somewhere with less memory available, and it will work the
| same way
| yellow_lead wrote:
| But is there any way to limit the memory? Sometimes I want to
| run more than one thing on the box. I found that meilisearch
| doesn't have a "max total memory use" flag
| irevoire wrote:
| Hey, as the previous person said you cannot really limit
| the memory, Meilisearch uses.
|
| But your OS will share the Meilisearch memory with other
| process seamlessly, you don't have anything to do. In htop
| it's the yellow bar, and it's basically a big cache shared
| between all processes.
| mitchitized wrote:
| Fire it up in a docker container and limit the RAM usage that
| way.
|
| This is a trick I learned years ago with other mmap-based
| systems.
| irevoire wrote:
| Are you sure it really limits the RAM? You're still using the
| same kernel, and if a process is using more memory than
| another one I would expect the kernel to keep more of its
| memory page in RAM than the other.
|
| What was your strategy to measure that?
| mentalgear wrote:
| Notable alternative Orama: https://github.com/oramasearch/orama
|
| > complete search engine and RAG pipeline in your browser, server
| or edge network with support for full-text, vector, and hybrid
| search in less than 2kb.
| amazingamazing wrote:
| I wish these had pluggable backends separate from the actual
| implementation of indices so you could use your own store, rather
| than have to sync constantly. The performance would likely be
| worse, but at least you don't have to worry about staleness when
| rehydrating...
| subpixel wrote:
| On their homepage, using vanilla search, I entered the first word
| of a particular funny movie and it was third result.
|
| Switching on the AI toggle, I entered the same word, and got no
| results.
| Alifatisk wrote:
| There is also typesense
| saintfiends wrote:
| Meilisearch is really good for a corpus that rarely changes from
| my experience so far. If the documents frequently change and you
| have a need to have those changes available in search results
| fairly quickly it ends up with pending tasks for hours.
|
| I don't have a good solution for this use-case other than maybe
| just the good old RDBMS. I'm open for suggestions or anyway to
| tweak Meilisearch for documents that gets updated every few
| seconds. We have about 7 million documents that's about 5kb each.
| What kind of instance do I need to handle this.
| Kerollmops wrote:
| The best you could do is put Meilisearch on a very good NVMe. I
| am indexing large streams of content (Bsky posts + likes), and
| I assure you that I tested Meilisearch on a not-so-good NVMe
| and a slow HDD -- and ho, Boy!! The SSD is so much faster.
|
| I am sending hundreds of thousands of messages and changes (of
| the likes count) into Meilisearch, and so far, so good. It's
| been a month, and everything is working fine. We also shipped
| the new batches/ stats showing a lot of internal information
| about indexing step timings [1] to help us prioritize.
|
| [1]:
| https://github.com/meilisearch/meilisearch/pull/5356#issue-2...
| brandonlovesked wrote:
| You have 35gib of data, put it in memory and forget about nvmes
| and hdds
| Kerollmops wrote:
| 35 GiB is probably a third of the data I index into
| Meilisearch just for experimenting and don't forget about the
| inverted indexes. You wouldn't use any O(n) algorithm to
| search in your documents.
|
| Also, every time you need to reboot the engine you would have
| to reindex everything from scratch. Not a good strategy,
| believe me.
| adrianvincent wrote:
| I have been using Meilisearch for https://www.comparedial.com/
| since the early alpha versions. Ridiculously easy to set up
| compared to alternatives.
| justAnotherHero wrote:
| We have been using Meilisearch with firebase for years and it has
| always worked great. I just wish they would update the extension
| on the firebase extensions hub[1] because the current version
| available uses node 14 which is not supported by cloud functions
| on GCP so the extension is not usable at all. What's weird is
| that the latest version available on their repo has upgraded the
| node version but they are not offering it in the extensions hub.
|
| [1]: https://extensions.dev/extensions/meilisearch/firestore-
| meil...
| softwaredoug wrote:
| One thing to _always_ dig into is how your hybrid search solution
| filters the vector search index. This is not at all standardized,
| often overlooked, but when you want "top X most similar to query
| by embedding, but also in Y category/match Z search terms" its
| the core operation your hybrid search is doing
|
| Here's a rollup of algorithms...
| https://bsky.app/profile/softwaredoug.bsky.social/post/3lmrm...
___________________________________________________________________
(page generated 2025-04-14 23:00 UTC)