VMware Tanzu Data Solutions Reviews

We use it as our main microservices connection queue.

The product's reliability is the most valuable feature.

• The product has to improve the crisis management, especially in memory issues.
• Its clustering feature also needs improvement.
• I would simplify the configuration. I would add default configuration that prevents the queue system from filling out the server storage.
• I would also decouple the queue from the RabbitMQ Management, so that the queues won't get stuck.
• Clustering and clustering crisis management: When the cluster falls, there needs to be a simple way to recover it. It currently suffers from a recover problem.

In the regular state, there were no stability issues. When the queues are full, only complicated pre-configuration can help you so that you don't lose all of your crisis messages.

There were some scalability issues. There is no scalable queue. The cluster only supports redirections.

The documentation needs to be improved. We don't use any human technical support.

We have used DBus and ZeroMQ. We wanted something more reliable and simple, so we switched over to this tool.

The setup was okay, but there are some configurations that one needs to do by oneself. There are many dependencies as well.

It is an open source solution.

Do many stress tests.

My company runs on high availability. It is known for high accuracy in its items that are being shipped.

To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy.

Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create 'queues' on the fly and pass messages from one system to another.

• Queues and topics
• Native cloud app support
• Light-weight
• Easy maintenance
• Simple and straightforward admin portals: Made it easy for users and worked out excellently for our requirements

The solution needs improvement on performance.

It was stable enough to process our requests.

We were able to operate multiple nodes and we implemented a load balancer to meet our high traffic requirements.

We have never needed technical support. It was all there in the API documents provided by RabbitMQ and there are numerous blogs available on internet.

We analyzed our requirement thoroughly and were sure that RabbitMQ was the solution for us. We didn’t look at anything else.

It was bundled with PCF, so it was never a problem for us.

Again, it was part of PCF bundle, so that was never a worry for us.

This is a great product. It is lightweight, supports cloud native applications, is easy to implement, is easily manageable, and has excellent support. I would say, just go for it!

Greenplum is an MPP architecture database. Data can be distributed across multiple nodes and strong distribution will allow queries to execute on all segments at once, which is very powerful. As long as we have good SQL knowledge, we can start playing in the platform. Greenplum uses Postgres and ANSI Standard SQL. Also, it supports many other procedural languages, such as Python, C++, and Pearl.

Greenplum is a high powered, multi-node database that was chosen for its capacity to ingest and query data at extremely high rates of speed, enabling in Database Analytics and Statistical output on granular levels of data that was otherwise inaccessible before its deployment. We were able to analyze and produce output on large volumes of data very quickly which saved us lots of time (we used to wait for hours to get the same output). The management was able to get insights very quickly so that they can make informed decisions.

I used Greenplum between Aug 2011 – Aug 2015. Almost all the members in the analytics team used Greenplum on a daily basis.

There were no issues, and it was doing what it was supposed to do.

There were no issues, and it was doing what it was supposed to do.

We had a pre-sales consultant who provided end-end solution about the product. Also, he was working with our data and clearly demonstrated the advantages of Greenplum. After we purchased the product, we were provided a full time consultant who had extensive knowledge about the product. He was primarily responsible for providing hands on experience on projects and also did excellent job of teaching everyone and bringing everyone up to the speed on the new platform. We also had a technical person offshore who was responsible for fixing things if something breaks up or any other issues.

We did use other products in the company but it wasn’t an MPP architecture database. Our data was getting bigger so we needed something with MPP architecture to tackle big data challenges so Greenplum was considered. It was a management decision to purchase this product (not sure whether other similar products were considered or not)

All the set up I believe was done by Greenplum team.

I didn't have any visibility on the pricing and licensing. But I can say that, we needed product like Greenplum to store, manage and analyze huge volumes of data which can be daunting task

Greenplum is a MPP (massively parallel processing) database which is extremely fast. If people are dealing with very high volume of data, it is definitely a product to consider seriously

Guaranteed message delivery, queuing, and low latency delivery.

This allowed us to create a resilient network and independently scale various parts of the system dynamically as the business needs changed.

The biggest area we struggled with was operations troubleshooting. We were running a pretty big cluster and ended up with some random cluster failures that were difficult to troubleshoot. A good portion of these were self inflicted but occasionally the distributed database would end up corrupted.

I have been using RabbitMQ for six years, from prototype to production.

We had a bit of an issue with stability. The usual initial cause would be a hiccup in IOPS in EC2 but then this would cascade into more instability in our main clusters.

For the most part the product was very scalable. The only times we would have problems were usually related to Amazon hiccups that would cause the cluster to slow down.

We did not use their technical support much.

We evaluated a variety of message products and found that for the feature set RabbitMQ was the best.

Initial setup was relatively simple and then we were able to grow into the product by using more of the features.

We used the open source implementation and did not need to pay for support.

We looked at ZeroMQ, Kafka and Redis.

You really need to have or train Erlang expertise. The Erlang tools will become the best way to troubleshoot misbehaving clusters.

We're using this as our central messaging bus. It drives our micro-service architecture.

• Great management UI: The best in its class of messaging products
• Very sophisticated routing control and priority messaging capabilities

• The product should have much better scaling and scalability capabilities. Currently, they're really falling behind some of the competitors such as Kafka and NSQ.
• The installation of the HA version and clustering mechanism should be made much easier.
• The fact that a single queue can't be distributed across multiple instances/nodes is a major disadvantage.

We had multiple issues with stability. The product tends to be highly unstable when under heavy loads.

We had multiple issues with scalability. The product's scalability is rather problematic. It tends to be very complex to maintain with various sharding and high availability options.

I have never used technical support.

We tested some earlier version of Apache Kafka, but it wasn't stable enough at the time. At the moment, we're considering switching back to Apache Kafka.

The non-sharded/clustered setup is very easy and straightforward. The clustered solution setup is much more complicated.

We have only used the open source version.

We evaluated Apache Kafka, NSQ, and ActiveMQ.

Check the scaling issues. If scale is not an issue and you're just looking for a stable messaging queue, I would highly suggest it.

If scale is an issue, I would suggest using Apache Kafka.

• Load balancing through queues
• Guaranteed messaging
• Configurable pre-fetch count
• Queue mirroring

RabbitMQ helped us build a database synchronization framework that allowed us to transfer our clients data to our cloud based data processing centers.

The web management tool.

I have used this solution since 2013.

We had several de-clustering problems.

We did not have any scalability problems.

I have never used support.

This is the first solution we implemented.

It was a very simple setup. We had some issues with the home folder being on a non-standard system drive (The location of the RMQ cookie was changed.)

The Community Edition works fine for us.

We evaluated several other solutions; the MQSeries and MSMQ.

Use it for implementations that require a queuing solution. It is easy to overuse it as a universal communication bus of the entire system.

The most valuable features for us are speed and persistent messaging.

We are now able to leverage real time applications and event driven architecture.

The documentation needs to be improved. There's a learning curve on setting it up and there are issues arising from slower networks that they lack documentation on.

We have been using the product for three years.

Stability issues experienced were only due to a slow network at the client.

We did not encounter any scalability issues.

I never used the technical support.

I am not aware of any previous solutions.

We are a container shop and the only issues during setup were around proper clustering and configuring the application to use it.

We evaluated Apache Kafka also.

I would advise potential customers to use something to wrap their interaction, like Spring for Java.

Complex message routing makes it very easy to replicate product data for user acceptance testing which was required in our user case.

Applying message queues in general has helped my company, BuzzNumber, to scale easily with the load.

The High Availability feature is not really reliable. It also took a really long time to restart the box when there were a lot of messages in the queue.

As mentioned on its document page, it cannot tolerate network partition well.
I suffered a network parturition with 3 nodes cluster and lost all data. So with our cloud provider, we can’t rely on pause_minority and seems like auto_heal is a better fit for us.

Apart from that, RabbitMQ doesn’t seem to be stable when it has high RAM usage. Especially when you have millions of queue items in a queue and a node crashes, adding a new node to such cluster will be a pain as the replication takes forever.

We have used the solution for two years.

We encountered an issue with stability. It didn't work very well with millions of messages in the queue when you add a new node to the cluster.

There were no specific issues with scalability except the issue of adding a new node to the cluster.

We used the open source version with community support, so we didn't contact technical support.

We previously used MSMQ. Apparently, it is not as good as RabbitMQ in terms of the features offered.

The setup is easy.

This is not applicable, as we were using the free version.

I am not aware of other evaluated options.

I would advise potential customers to make sure it works with your architecture, scale plan, and load. There are other alternatives.