pg_search VS Searchkick

Facets are possible in Postgres but it looks complex:

https://web.archive.org/web/20200815141031/https://roamanaly...

pg_search [0] not to be confused with the ruby gem of the same name [1]:

[0] - https://github.com/paradedb/paradedb/tree/dev/pg_search#over...

[1] - https://github.com/Casecommons/pg_search

On the backend, we'll need a few tools. Apart from the classics (ActiveRecord scopes and the pg_search gem), you’ll see how the (yet officially unreleased but production-tested) all_futures gem, built by SR authors, will act as an ideal ephemeral object to temporarily store our filter params and host our search logic. Finally, we’ll use pagy for pagination duties.

You can take a look at pg_search if you’re using Postgres

This was a really good read, thanks. I've got into the habit of jumping straight to PgSearch but could definitely apply this approach to some existing projects.

Cleaner, more performant database queries: Definitely don't just leave your query sitting in the controller! For production use cases, you'd want to consider an option like pg_search

If you are using Rails with Postgres you can use pg_search gem to build the named scopes to take advantage of full text search.

https://github.com/Casecommons/pg_search

Hey guys. Looking to release an app for mobile that will be using a rails API. The app will heavily rely on search. I know the go-to is to use elasticsearch but wanted to see if there was enough user demand for the MVP before shelling out $50/mo for the heroku add on. In the mean time I've been using pg_search. From the eye test it's performing okay but will be adding a table that houses over 350K records. With this in mind I was wondering if you all had any tips for increasing the overall speed for search from the model and controller level. Also should note that I'm open to any other free search gems if they deem bette fit.

There are two basic search configurations with pg_search, a Single Model search scope or a multi Model configuration. In my case I am only using the Single Model configuration, but you can read more about multi-search in the documentation.

Yesterday, I worked on elasticsearch integration with help of searchkick.

I run a large scale production application that does something along these lines. If the data needs to be close to real-time, I'd say use `searchkick` + Elasticsearch, and use `searchkick`'s async feature to "stream" the data from your table to the ES index. Your dashboard will then just query from the ES index via searchkick.

You're right, that's actually what we implemented, application-level hooks, but they needed development and maintenance effort that come for free with the adapter we're using for OpenSearch integration, which also comes with welcome features: synonyms, partial matches, and many others.

Spoiler, the adapter is Searchkick: https://github.com/ankane/searchkick

Searchkick

Normally for Rails applications you would use a gem like searchkick since it greatly reduces the initial Elasticsearch complexity.

We lean heavily on Elasticsearch at CompanyCam. One of it's primary use cases is serving our highly filterable project feed. It is incredibly fast, even when you apply multiple filters to your query and are searching a largish data set. Our primary interface for interacting with Elasticsearch is using the Searchkick gem. Searchkick is a powerhouse and provides so many features out of the box. One place where we bump up against the edges is when trying to reindex a large collection.

Convinced? Ok read on and I’ll show you what switching from Elasticsearch to Meilisearch looked like for a real production app — ScribeHub. We also moved from Ankane’s excellent Searchkick gem to the first party meilisearch-rails gem and I’ll show you the changes there as well.

If you want to use a look-aside pattern (like you might have used with Searchkick + Elasticsearch), you should check out ActiveStash: https://github.com/cipherstash/activestash