I'd say that the bit where typesense can only work with data that fits in ram is actually a pretty big problem for a lot of use cases, as an aside. That feature alone would discount typesense for basically all of my personal projects. Might be a trade off I'd be willing to make on a professional project given the other features but it seems really wasteful.
Of course I'm not a large enterprise e-commerce site. I'm doing personal projects like web archiving, (dataset probably won't be anywhere near fitting in ram) or I'm using search engines on embedded devices (search needs to play well with others, not use all my ram).
There's a big difference between recommended and required. Of course things work better if your entire dataset fits in ram, and of course at the giant enterprise scale you can do that, but it's not something I'm going to do on my VPS along side wordpress, you know? I don't really care about getting maximum possible performance when the data is only going to be accessed intermittently. I care about letting the OS maximize performance by choosing what gets cached in ram.
Typesense follows a memory model similar to Redis - you need sufficient RAM to hold the entire dataset.
I don't want to speak for the Meilisearch team, but from observing user reports like this [1], it seems to me like you'd need at least X-2X RAM to run Meilisearch, if X is the size of your dataset, if you want it to not slow down as it swaps content from Disk to RAM.
I mean that user report is from me, and was about a very very early meilisearch version. Maybe wrong link?
> if you want it to not slow down as it swaps content from Disk to RAM.
Obviously it's going to be fastest to run with your entire dataset in RAM, that's never in doubt. Part of why I find the whole typesense comparison page disingenuous is that you're making the ability to swap to disk sound like an anti-feature. The whole things just sounds biased in a way that the meilisearch comparison doesn't.
There are some killer features in typesense for sure, just my first impression of it is that it's very much aimed at someone other than me.
>Typesense follows a memory model similar to Redis
The difference is that redis is primarily being used as a cache, or for IPC, or as a task-queue. You're not loading a whole bunch of data into, and you expect that the data you have in it will either be short-lived (IPC, queue) or can be evicted with no issues (caching).
Hmmm, I remember those emails and I did reply to gmourier, and made almost all of the changes he pointed out, to our comparison page. Here's [1] the exact commit with the changes I made.
The only one change I didn't make is the one about Meilisearch not being constrained by RAM, because of reports like this [2] I've seen in the past and because I saw this in your docs:
>For the best performance, it is recommended to provide the same amount of RAM as the size the database takes on disk, so all the data structures can fit in memory.
they are very similar. I've tested both intensively a few months ago, ended up w Typesense for performance reason.
My test data set is 1.5M doc * 3-10 fields * 10-50 characters. Meilisearch has slightly better multi-language support, but typesense is much better on batch reindex speed and ram usage while a bit shy on supporting asian languages. The query speed is similar in light to medium load, I didn't stress test on query.
You should try it again since we intensively improved the indexation performances. Most of our actual users no longer have performance problems, even on hundreds of millions of documents.
https://docs.meilisearch.com/learn/what_is_meilisearch/compa...