Bringing full text search to Elixir's Ecto | Hacker News Reader

Bringing full text search to Elixir's Ecto

moosie.us

86 pointsphilippemnoel11 comments

That database sounds like scam created by junior programmers that invest the major part of their VC budget money into marketing instead of engineering. I don't believe that they are even fully aware of all functionality of ES that they are comparing to.

AHAHAHAHAHAHAHAA

HAHAHAHAAA

This is perfect. If I was on the team, I would have this framed and hang it up in the office, to get a good chuckle every time I walk by.

I recently did a quick research about fulltext engines and found it to be very frustrating.

The most promising with a comment /note:

  ElasticSearch - good, but huge and strange licensing
  Meilisearch - my favorite, nothing to complain so far
  QuickWit - good but *nix only
  TypeSense - good but *nix only
  Manticore - untested but looks interestung
  ZincSearch - seems abandoned, issues with ES API compatibility
  Solr - interesting but a bit old fashioned
  Sphinx - DB based, old fashioned

AFAIK ES and Solr are both built on Lucene so they are either both DB based or neither, surely? Not sure what you mean by DB based.

Is "old fashioned" such a bad thing?

Thanks for the list. Several things that might be of interest to me at some point .

With DB I meant SQL / DBMS based. Most DBMS have support for fulltext, while mostly nowhere near the performance or featurette of specialized systems.

Elastic, solr and others are based on lucene, and while old fashioned is nothing Bad, it may lack features like extended monitoring, distributed services or optimizations for modern Hardware.

Did you look at Vespa? I used the Yahoo internal version of it way back when, and would try the public version if I had search needs again.

Isn't this cloud based? (that's not what I was looking for)

For Vespa there's a managed version hosted by the Vespa company in their cloud environment, and then the open source version is easily run locally or in any environment of your choosing. It takes some attention to detail, but it's quite flexible. I have a long running single node instance on an Intel NUC, but I've also run more complex cluster variations across different cloud environments.

+1 for replacing ES with ParadeDB. I did this for one of my projects recently and it's working just fine for my use case (FTS), with much less overhead. The DXP could use some improvement, but I think they'll get there. Good to see ParadeDB getting more traction.

There's a pre-existing aws-s3 extension allowing for s3 object connectivity. A duckDB extension is very different from this in scope. Also, s3 file access seems to be referred to as data lake access? Confused.

Reply on news.ycombinator.com