Not enough information. It looks far more like he's testing Ruby's support for ElasticSearch vs ActiveRecord rather than ES vs PostgreSQL. Caching could definitely hold a role but also choice of indexes. If ES is calculating some aggregate info on the fly, the equivalent in PG would be a stats table updated by trigger or as part of a regularly refreshed materialized view. That said, if ES does some of that aggregation out of the box, the convenience by default is compelling for some.
There are indeed cases where a caching engine will outperform a general purpose data management engine. There are many cases where ACID requirements preclude the use of a dedicated search engine. Use the right tool for the job, and for a sufficiently large scale, use multiple tools. On Mon, Jul 8, 2019 at 9:54 AM Guyren Howe <guy...@gmail.com> wrote: > I find this… surprising. Caching? > > http://blog.nrowegt.com/database-vs-elasticsearch-speed-column-statistics/ >
