[binarymax]

For personal use nobody cares about 100ms vs 10ms response. What they do care about is relevance. Consider the following from those repo outputs:

Typesense

    [timing] phrase [superman]: returned [28] results in 4.222797.ms
    [timing] phrase [suprman]: returned [28] results in 3.663458.ms

SQLite

    [timing] phrase [superman]: returned [47] results in 0.351138.ms
    [timing] phrase [suprman]: returned [0] results in 0.07513.ms

So SQLite is faster, but who cares? I want things like relevance and typo resilience without having to configure anything.

[evdubs]

The article covers typo resilience in the section "Typo tolerance / fuzzy search".

This adds a step between query entry and text search where you find the similarity of query words to unique lexemes if the word is not a lexeme. Seems like a reasonable compromise to me?

[bshipp]

I'm not trying to be argumentative. As long as people find a solution they're happy with, I think that's great. For me, I'm far less interested in handling typos, but I can see how it would be valuable in many applications. I'm usually less interested in tying in and learning another set of services if I can get 90% of the way there with one, but leaving the option of adding it later if additional requirements make it necessary.