jabo

Mercury

Wonder if white noise counts as noise from this perspective. Or if it’s mainly unexpected noises that make sleep quality worse.

The day I discovered that marquee tags have a direction attribute, using which you can make the text go up/down left/right and use multiple of these tags, is still etched in my memory.

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.

If anyone's interested, a while ago I downloaded the MusicBrainz database and built a search-as-you-type experience here with about 32M songs:

https://songs-search.typesense.org

The dataset has been very helpful to benchmark Typesense across releases. So I'm grateful that it exists!

We’ve interacted before on Twitter and GitHub, and I want to address your point about Raft in Typesense since you mention it explicitly:

I can confidently say that Raft in Typesense is NOT broken.

We run thousands of clusters on Typesense Cloud serving close to 2 Billion searches per month, reliably.

We have airlines using us, a few national retailers with 100s of physical stores in their POS systems, logistic companies for scheduling, food delivery apps, large entertainment sites, etc - collectively these are use cases where a downtime of even an hour could cause millions of dollars in loss. And we power these reliably on Typesense Cloud, using Raft.

For an n-node cluster, the Raft protocol only guarantees auto-recovery for a failure of up to (n-1)/2 nodes. Beyond that, manual intervention is needed. This is by design to prevent a split brain situation. This not a Typesense thing, but a Raft protocol thing.

I'm biased, but I'd recommend exploring Typesense for search.

It's an open source alternative to Algolia + Pinecone, optimized for speed (since it's in-memory) and an out-of-the-box dev experience. E-commerce is also a very common use-case I see among our users.

Here's a live demo with 32M songs: https://songs-search.typesense.org/

Disclaimer: I work on Typesense.

Here's an example of semantic search:

Let's say your dataset has the words "Oceans are blue" in it.

With keyword search, if someone searches for "Ocean", they'll see that record, since it's a close match. But if they search for "sea" then that record won't be returned.

This is where semantic search comes in. It can automatically deduce semantic / conceptual relationships between words and return a record with "Ocean" even if the search term is "sea", because the two words are conceptually related.

The way semantic search works under the hood is using these things called embeddings, which are just a big array of floating point numbers for each record. It's an alternate way to represent words, in an N-dimensional space created by a machine learning model. Here's more information about embeddings: https://typesense.org/docs/0.25.0/api/vector-search.html#wha...

With the latest release, you essentially don't have to worry about embeddings (except may be picking one of the model names to use and experiment) and Typesense will do the semantic search for you by generating embeddings automatically.

I work on Typesense [1] - historically considered an open source alternative to Algolia.

We then launched vector search in Jan 2023, and just last week we launched the ability to generate embeddings from within Typesense.

You'd just need to send JSON data, and Typesense can generate embeddings for your data using OpenAI, PaLM API, or built-in models like S-BERT, E-5, etc (running on a GPU if you prefer) [2]

You can then do a hybrid (keyword + semantic) search by just sending the search keywords to Typesense, and Typesense will automatically generate embeddings for you internally and return a ranked list of keyword results weaved with semantic results (using Rank Fusion).

You can also combine filtering, faceting, typo tolerance, etc - the things Typesense already had - with semantic search.

For context, we serve over 1.3B searches per month on Typesense Cloud [3]

[1] https://github.com/typesense/typesense

[2] https://typesense.org/docs/0.25.0/api/vector-search.html

[3] https://cloud.typesense.org

We don't plan to support external vector databases, since we want to build Typesense as a vector + keyword search datastore by itself.

Typesense has a vector store / search built-in: https://typesense.org/docs/0.24.1/api/vector-search.html

In the upcoming version, we've also added the ability to automatically generate embeddings from within Typesense either using OpenAI, PaLM API or a built-in model like s-bert or E5. So you only have to send json and pick a model, Typesense will then do a hybrid vector+keyword search for queries.

We've been using Struct's Slack bot in Typesense's Slack community here (if you want to see a demo of how it looks):

https://threads.typesense.org/kb

I love that the discussions we're having (in public channels) are now automatically indexed and made searchable publicly to any users who are looking for information on Google, etc, even if they're not a part of our Slack community.

I previously used to be worried about all this time and effort we're putting in to a walled garden of information that Slack was becoming, not to mention their untenable pricing for communities.

I now find myself spending more time writing more detailed answers in Slack, because I know it's going to be available publicly for future searchers.

You can also use this library with Typesense, which is an open source alternative to Algolia: https://github.com/typesense/typesense-autocomplete-demo

Disclaimer: I work on Typesense.

Typesense: https://typesense.org/docs/0.24.1/api/vector-search.html

I get this question frequently - why not use FAISS or ANNOY directly, instead of a vector database, so glad to see this aspect covered in this article.

Plug: If you're ever looking for an open source alternative to Pinecone, we recently added vector search to Typesense: https://typesense.org/docs/0.24.1/api/vector-search.html

The key thing is that it's in-memory and allows you to combine attribute-based filtering, together with HNSW-based nearest-neighbor search.

We're also working on a way to automatically generate embeddings from within Typesense using any ML models of your choice.

So Algolia + Pinecone + Open Source + Self-Hostable with a cloud hosted option = Typesense

Yup. If you store timestamps as Unix timestamps you can gave Typesense sort on text match score and the timestamp field: https://typesense.org/docs/guide/ranking-and-relevance.html#...

Plug: If you're ever looking for an open source alternative to Pinecone, we recently added vector search to Typesense: https://typesense.org/docs/0.24.1/api/vector-search.html

The key thing is that it's in-memory and allows you to combine attribute-based filtering, together with nearest-neighbor search.

We're also working on a way to automatically generate embeddings from within Typesense using any ML models of your choice.

So Algolia + Pinecone + Open Source + Self-Hostable with a cloud hosted option = Typesense

If I'm reading this correctly, it looks like search requests are now charged separate from the number of documents.

So if I have 5M records and 5M searches per month, in the old pricing scheme I would have paid $5K per month.

In the new pricing plan, I would pay $0.40 per 1K records and then $0.50 per 1K searches. So that's $2K for record storage and $2.5K for search requests for a total of $4.5K.

This blog post [1] claims they've slashed prices by 50%, which may be true at the unit level, but then it sounds like they've separated out charges for searches and records, so you still end up paying close to what you used to pay previously...

Am I misreading something?

[Disclaimer: I work on Typesense, an open source alternative to Algolia with a SaaS version, so I'm looking to understand this better myself.]

[1] https://www.algolia.com/about/news/algolia-introduces-new-de...

We added HNSW-based vector search to Typesense as well recently: https://typesense.org/docs/0.24.0/api/vector-search.html

So you can combine attribute-based filters along with nearest-neighbor search.

Put together this semantic search + filtering demo just last week: https://github.com/typesense/typesense-instantsearch-semanti...

This seems like the central page that FDIC is using to communicate the latest news.

This FAQ document has more tactical next steps: https://www.fdic.gov/resources/resolutions/bank-failures/fai...

I second this. Thank you for sharing!

I wonder if this is a custom visualization pattern, or if there is general a name for this type of visualization. Does any one know?

I really appreciate that you took the time to write this detailed comment! Thank you!

but for me one example of production looks like a raspberry pi in a school house in rural africa (internet in a box project)

This is an interesting perspective, one that I hadn't considered before. You're saying that software can be run in a variety of different environments and that the definition of what a "production" environment looks like is context-dependent.

My definition of "production" in the context of server software is that you typically run this software on a server or set of servers in some datacenter (think Redis, Postgres, MySQL, MongoDB, etc). In this context, I've always defined "production-ready" as:

1. Can it withstand infrastructure failures?

2. Is the API stable?

So when I say Meilisearch is not "production-ready", it's in this specific context - it can only be run on a single node, and it cannot handle infrastructure failures natively. So it could become single point of failure.

This here is another spot where you seem biased. Remove the "despite v1.x versioning", it comes off as petty.

Historically I've seen server software has fault tolerance built-in when they reach v1.0, and it's a common assumption that I've seen engineers make. So I wanted to call attention to it... The phrasing of it comes across as petty, now that you mention it. I'll remove that.

I get what you're saying about "production ready" but there must be another way to word it?

I think "fault tolerance" is a better word to describe what I had in mind. I'll update this.

I don't think either of you support https.

Typesense does support https natively.

Do you really not recommend the use of a reverse proxy? ... I guess you're assuming it's running on a stand alone computer with a public facing IP... ? Are you not providing a frontend/dashboard?

Yes to all your questions, except that Typesense does support HTTPS natively.

You've made this sound like a draw back, if you had of put "None. Self-contained binary" in front of it like you did for yourself that would be fine but for this you mention a feature that you have while ignoring what looks to me like the same feature in your competitor.

I was actually going to add "None. Self-contained binary" for Meilisearch. But then their docs explicitly recommend using a reverse proxy in front: https://docs.meilisearch.com/learn/cookbooks/running_product...

With Typesense, we use h2o as the http library, which for eg Fastly exposes directly to internet-bound traffic and it's specifically built for handling high-volume traffic. This is why we feel comfortable recommending not putting a reverse-proxy in front of Typesense.

Language support... This is also a bit confusing, and I can't help but think it's probably not completely honest. What makes meilisearch different so that it doesn't support "all languages", but elasticsearch does? Meilisearch certainly claims to support all languages where words are seperated by spaces, do you support languages that don't have words separated by spaces?

Yes, we support all languages that are space-separated. We also added support for CJK languages recently (which are not space-separated). I picked the phrasing you see under the Meilisearch column, from their docs: https://docs.meilisearch.com/learn/what_is_meilisearch/langu... (it used to read slightly different previously).

Meilisearch is multilingual, featuring optimized support for: Any language that uses whitespace to separate words Chinese Japanese Hebrew Thai We aim to provide global language support, and your feedback helps us move closer to that goal.

This user claims that meilisearch has better multi-language support: https://news.ycombinator.com/item?id=34708802

We didn't support CJK languages in a GA release, until 2 weeks ago. So they are most likely talking about an earlier version of Typesense.

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.

Didn’t intend it that way. In fact, we recommend that users configure swap space even in Typesense as a safety mechanism.

May I know which part of the comparison table makes it sound like that?

The one under Index location says: “Disk with Memory Mapped files” for Meilisearch, which I updated based on the Meilisearch team’s feedback…

Edit: To your first point, I meant to link to the parent comment: https://news.ycombinator.com/item?id=34708352

I’ve also seen similar RAM recommendations from the Meilisearch team on GitHub to other users reporting similar performance issues.

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:

https://docs.meilisearch.com/learn/advanced/storage.html#mem...

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.

[1] https://github.com/typesense/typesense-website/commit/0103ff...

[2] https://news.ycombinator.com/item?id=34708658

Let me know which other ones need updating.

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.

[1] https://news.ycombinator.com/item?id=34708658

I maintain that comparison page on the Typesense side. I just updated it as recently as yesterday, based on my observation.

But let me know which ones need updating for Meilisearch. Happy to update.

While we’re on the topic, reminder about some of the outdated information in your comparison pages: https://twitter.com/typesense/status/1620825236055932928?s=4...

I’ve come to see it this way:

If a set of users are using a product only because it is built in X, that user base is most likely the early adopter audience for X and it dangerously masks whether that product has product-market fit or not.

So if a product markets itself as built in X, it is appealing to early adopters of X.

The long-tail of users on the other hand, care more about what painful problem the product is solving for them.

Now, some of the features of X might provide benefits to end users, but the long tail of users care more about those benefits they get rather than the fact that X provides those benefits, and that the product uses X.

Disclaimer: I work on Typesense [1] (an open source alternative to Algolia + Pinecone) and we recently added Vector Search as a feature to Typesense [2].

Postgres can do a lot of things, but for large enough datasets and/or when you want to add filtering into the mix along with vector search, then it becomes slow. And at that point you want to use a dedicated vector search database.

It's similar to how Postgres can also do full text search, but for large datasets and/or you want to add typo tolerance, faceting, grouping, filtering, synonyms, etc - the usual features you'd need when implementing a search feature - then it becomes slow to do this in pg and you'd then use a dedicated search engine.

In Typesense, we've now combined Vector Search along with filtering based on attributes in your documents, so you get the best of both worlds [2], and we made it fast with an in-memory index.

[1] https://typesense.org/

[2] https://typesense.org/docs/0.24.0/api/vector-search.html

Had this happen to me too. For a second, I was wondering if the title of this HN post and the Google redirect was some sort of joke I didn't understand.

This is going to make time zone math a bit more complicated than it already is.