Perfomance Metrics?

[ylluminate]

We've been having some consistent problems with ElasticSearch and are nearly convinced to move away from it in an effort to simplify things since we're already using PGSQL.

Does anyone have any performance metrics that are current to April 2015 for pg_search results vs the other usual options?

I've seen some interesting discussion here:

• (one benchmark is quite dated; 2009) http://stackoverflow.com/questions/10875674/any-reason-not-use-postgresqls-built-in-full-text-search-on-heroku
• Is Postgres full-text search as flexible and easy to implement as Elasticsearch in a Rails app? codeforamerica/ohana-api#139

[marshall-lee]

These links are interesting and reveal some truth but anyway you should do all the benchmarks yourself against your data and with your specific queries to this data because performance is highly dependent on data characteristics. Benchmarking random reads / random writes on random data won't reveal a whole picture.

[nertzy]

Yes, when using something like ElasticSearch you have a completely different architecture with a large number of variables, not limited to:

• how the data is distributed
• the nature and complexity of the queries
• hosting PostgreSQL and ElasticSearch on the same server or on a different server as the application
• network latency
• CPU / memory power on each machine
• indexes
• versions of PostgreSQL and ElasticSearch

So it's outside of the scope of this project to provide any sort of performance metrics. I'd welcome anyone to blog about any performance testing they've done for their individual use cases. It would be useful to add a wiki page outlining things like this.