Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
1–10 of 17 posts
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#2[author] Part 1 was on HN last week here: https://news.ycombinator.com/item?id=36699016
Happy to answer any questions. As with any DB comparison, it's tricky and I might have errors or I might have missed obvious things.
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#3To me, the critical points here are:
> PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding.
> if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better
I love the mentality of "default to using Postgres for everything, and specialize when you need to." In this case, it looks like you'll need to evolve text search out of Postgres the moment your dataset gets into the millions, which roughly matches my experience.
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#4[author] Part 1 was on HN last week here: https://news.ycombinator.com/item?id=36699016 Happy to answer any questions. As with any DB comparison, it's tricky and I might have errors or I might have missed obvious things.
Thanks for writing this up! I really enjoyed the comparison. My team is considering moving some of our data to elastisearch out of postgres, and this analysis helps confirm some of our thoughts.
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#5It's not Postgresql vs. Elastic, it's Postgresql + Elastic:
https://github.com/matthewfranglen/postgres-elasticsearch-fd...
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#6I think the article needs to talk more about how you can combine a text search with a non text search criteria. I don't know about elasticsearch, but I guess that limiting it's search results to other bits of data, permissions, dates, relations, is harder than in postgresql.
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#7It's interesting to me, because we [I work at StarTree, based on Apache Pinot] come at the issue from the entirely opposite end of the scales — when Elasticsearch doesn't scale to certain very large data sets, and especially where you are looking for aggregations and low latency query results.
So there are some workloads that are small enough you can use a different an alternate to Elasticsearch (and where performance is not paramount), and other workloads that are sort of too big for Elasticsearch (and where performance is paramount).
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#8To me, the critical points here are: > PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding. > if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better I love the mentality of "default to using Postgres for everything, a…
We have billions of records and fts still works on pg.
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#9To me, the critical points here are: > PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding. > if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better I love the mentality of "default to using Postgres for everything, a…
We have billions of records and fts still works on pg.
That sounds interesting, are you using `ts_rank` or otherwise sorting by relevancy?
Re: Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch
#10FTS in all databases suck for non-English languages. Even the larger dedicated search systems often fail at even the simplest searches or need arcane configurations to work properly.