VMware Tanzu Data Services Reviews

We use VMware RabbitMQ to transfer information from one point to another. 

VMware RabbitMQ needs to create a new queue system. 

I have been using the solution for one and a year. 

My company has 10-15 users for VMware RabbitMQ. 

VMware RabbitMQ's installation is easy. However, it doesn't come with any manuals. 

You should use the solution if you want to store your details in the queue and start taking inputs from the queue. I rate it a nine out of ten. 

We use the solution for event-driven programming. We have multiple queues and channels to provide scenarios for publishing into containers. You have to communicate the microservices, and consumers consume the services. 

We were using the solution to setting the tenant settings into the service. For example, if you have five microservices using the tenant settings, after updated, we publish the updates to other microservices. It helps get the updated data to be able to publish the settings into the updated queue.

The queues and the publishing are quite useful. We're able to create hierarchies and control channels and flows to control what is going from which queue.

The solution can scale.

It is stable and reliable. 

The availability could be better. When something crashes, a queue gets deleted, and my data is lost. They need to improve this so that we don't lose data during issues like crashes.

We'd like to understand how many queues are running on RabbitMQ. I'm not sure how to get these details and how to verify the information.

We need other protocols. 

I've been using the solution for three years or so.

The solution is stable and reliable. There are no bugs or glitches. 

The solution is scalable. However, we have issues with availability. 

Sometimes, it is hard to understand what is going on when you reach out to technical support.

Our DevOps team deployed the solution. 

I'm not sure what the exact pricing is. I don't handle the licensing aspect. 

I am using the latest version of the solution. I'm not sure of the version number. 

I've used this on multiple projects, and it has proven to be quite useful.

I'd rate the solution nine out of ten. It is a very good tool. 

Tanzu Greenplum's most valuable features include: the integration of modern data science approaches across an MPP platform, including the ability to massively denormalize data and spread it across your MPP segments; the ability to index data and make it searchable, which significantly reduces the need for ETL; its fast performance. Tanzu Greenplum is also very active in providing additional functionalities and software when needed, like GPText indexing of JSON events.

Tanzu Greenplum's compression for GPText could be made more efficient.

I've been using Tanzu Greenplum for eight years.

Tanzu Greenplum's overall performance is outstanding.

Tanzu Greenplum is highly scalable.

VMware's technical support is probably the best I've seen.

The initial setup was very easy.

Tanzu Greenplum's pricing is really competitive and gives excellent value for money. I'd say that the benefits of orchestrated deployment and the features of GPText make the licensed version worth it.

When considering implementing Tanzu Greenplum, I recommend viewing it as a massive lakehouse, not just a data warehouse. I would rate Tanzu Greenplum ten out of ten.

We are using this product as a database for our platform. We are customers of VMware and I'm the project architect. 

In general, I think this is a very good platform, particularly as it's open source. It fits very well with use cases for public institutions or universities, where there is not always a big budget.

I'd like to see more support for structured data and features related to queries on NoSQL keys, extra filters would be helpful. 

I've been using this solution for two years. 

We've been working on this project and using this solution for two years and it's performed very well. 

The solution is scalable. We have around 20 users working directly on this platform and around 1,000 end users. 

We also use Cloudera and Oracle so we have a few alternatives. We currently use Greenplum because one of our customers needed an open-source solution that would scale well and after some investigation, we went with Greenplum. 

The initial setup was straightforward and we carried out the implementation ourselves. 

We're using the open-source version so there are no licensing fees. 

I recommend reading as much documentation as possible before starting to use the product. It helps to know how your data model should be implemented in order to get the best out of the platform and to figure out how it can improve performance, 

This is one of the best solutions I've used and I rate it eight out of 10.

Allowing for a fully asynchronous solution is crucial for this particular feature. The seamless nature of creating and connecting to a queue makes it really easy to code and understand. Pivotal Cloud Foundry allows us to easily scale the number of consumers (or receivers) as well. So far, no hiccups have been found with the PCF implementation.

RabbitMQ allows for asynchronous solutions where previously everything was synchronous.

The product works pretty well, but one small thing could be an improvement to the monitoring site. It could be a little bit more modern, instead of postback refreshing, etc.

We have been using Rabbit for a while and I started integrating it into the mobile project a few months ago.

Every so often, I need to clear out the queue during development. This could be a symptom of something else, but unpacked requests tend to get trapped in the queue at times.

PCF allows us to scale the consumers.

I haven't used any technical support yet.

To my knowledge, this is the only queuing system my company has used.

Thanks to Pivotal Cloud Foundry, initial setup was straightforward. We simply created a new RabbitMQ service, obtained credentials for the queue and started developing.

I personally have not explored other queuing solutions, but have used Akka HTTP, with is a fully asynchronous web server of sorts. It's not a queuing system, but I mention it because of the asynchronous behavior. RabbitMQ was perfect for our current solution, however.

The RabbitMQ documentation is pretty good. I'd only suggest making sure to read through it for the implementation language of your choice first.

I've found that the database warehouse, data compression, and ETL to be the most valuable features for us.

Loading batch data has really improved the efficiency of our organization.

I'd like so see better scaling, better performance from in-memory databases, and a higher compression rate. We have been facing some performance issue when doing batch loading with optimizer the scaling does works fine. They are working on having optimization techniques which made me write room for improvement.

I've used it for over two years. I have been working very closely with the EMC folks.

Yes, at times, but it depends on your modeling and data retrieval.

It's been stable for us.

Its scalability needs to be improved.

I would rate technical support as good and there is not much technical expertise at the start of the SR.

We tried other MPP’s.

It was complex, but there was a change in the setup.

We got support from the vendor at the start.

If you want to implement this product, you would need to scale your product well before trying to implement.

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!

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.