Denodo vs Elasticsearch

• Flat learning curve.
• Does not need brilliant developers.
• Less need for custom denodo wrappers, even if needed is not very complex.
• Denodo stored procedures and functions helped address complex, not straightforward requirements.
• Export/import deployment between environments was very helpful.

Read full review

• As I mentioned before, Elasticsearch's flexible data model is unparalleled. You can nest fields as deeply as you want, have as many fields as you want, but whatever you want in those fields (as long as it stays the same type), and all of it will be searchable and you don't need to even declare a schema beforehand!
• Elastic, the company behind Elasticsearch, is super strong financially and they have a great team of devs and product managers working on Elasticsearch. When I first started using ES 3 years ago, I was 90% impressed and knew it would be a good fit. 3 years later, I am 200% impressed and blown away by how far it has come and gotten even better. If there are features that are missing or you don't think it's fast enough right now, I bet it'll be suitable next year because the team behind it is so dang fast!
• Elasticsearch is really, really stable. It takes a lot to bring down a cluster. It's self-balancing algorithms, leader-election system, self-healing properties are state of the art. We've never seen network failures or hard-drive corruption or CPU bugs bring down an ES cluster.

Read full review

• Lack of Documentation and user community: Denodo continues to have a small community of super users, therefore there is not a lot of documentation out there in the event you get stuck.
• Cost: Data virtualization isn't cheap, so smaller organizations might shy away from this technology due to the high licensing costs.
• Caching strategy: Some slower datasets will require caching... which argues, why not just do traditional ETL if you need to do this?

Read full review

• Elasticsearch is highly distributed, but it takes time to tune so you get the right performance out of your cluster.
• The query language is not SQL, so it's not a straightforward conversion from an RDBMS to Elasticsearch for searching through data.
• There are lots of ways to insert data into Elasticsearch, and some are better than others (batch vs. single insert). Need to experiment with your own data and environment.

Read full review

• Improved time-to-market. We addressed new requirements in less than 2 person days.
• Very agile. Easy to handle changing requirements. Like a new requirement, a change in requirement was not expensive either.
• Platform issues were difficult to diagnose and debug.

Read full review

• When we where initially exploring logging solutions, Splunk was the only vendor in town and they where extremely expensive ($60,000). We haven't revisited them since as ElasticSearch has accomplished all of our needs.
• We haven't spent anything but Admin hours to maintain our ElasticSearch cluster. Right now we haven't incurred any cost of ownership as I have been maintaining the cluster myself.
• We have a huge project to grow a new part of our business, but I am not sure if I can spend the time to really update cluster to support the new Logstash features & any syntax changes so I am reluctant to do so. Time is increasingly becoming scarce, so catering to the latest and greatest features that offer little to our organization isn't something we are interested in pursuing though we are going to need to update the ElasticStack eventually.
• Since all of our metrics are in ElasticSearch, we have had nice trove of data to build our apps around, apps that require specific metrics. Prior to ElasticSearch, we had to build our own tools that handled that metric collection. The cost savings here is that we maintain a simple script that reports back information in our reporting interface vs rolling our own database metric solution that must be modified for every app we develop. That has equated to a huge saving in developer hours in our organization.

Read full review