VMware Tanzu Data Solutions Reviews

My team uses Greenplum for automating a lot of job writing scripts using PSQL. We use it to automate reports. Also, I use the identity workbench for logging in. In addition, I use DBeaver as well.

It works very well with large database queries. It works efficiently even in cases where you have a query worth terabytes of data.

Its most valuable feature is the ability to quickly run through data. It has a good processing speed as well.

They should improve product performance. It does not share resources well whenever it has more than one process running. If you have a user consuming a huge load size of resources, it takes down the entire system.

They should work on resource pulling and sharing those resources properly. At present, it allows one user to completely take over everything.

We have been using the solution for eight or nine years.

I would rate the solution about seven or eight out of ten for its scalability. Around 30-40 people in my organization are using the solution. We are not looking to increase usage. 

You eventually have to get new hardware because the CPU stops quickly once the load increases. It's only limited to hardware. You don’t realize you need new hardware until you have to because it doesn’t have throttles.

We have used Snowflake, Oracle, and many such solutions.

The setup seems pretty straightforward.

The solution has its limitations. It works better with a serial-threaded program than a multi-threaded program. If you go for the solution knowing that, you should be fine. I would rate the solution as a six out of ten.

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 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. 

We primarily use the solution for consumers and publishers. It's for messaging and consumer publishing. That's it.

The solution is simple to use.

It's great for messaging and consumer publishing.

Companies can scale the solution, so long as they have server room.

The stability is good.

The user interface could be improved. We have an interface that shows the consumption rate, the number of consumers, their occupation rate. We should have a column in that interface that shows the estimated time until, at the current rate of consumption, the number of messages is to be consumed from a specific queue. That would be great. I wanted to read, however, as it is right now, JavaScript would have loaded the browser too much. Basically, I'd just like to see the consumption rate in each queue without too much fuss.

The solution could use some plugins that could be integrated into the server installation. We had a plugin that we used to delay something that from one version to the other was integrated into the server setup. Maybe it was more of an extension. However, more plugins could be also be integrated into newer versions of Rabbit.

I've used the solution since 2013 or 2014. It's been about eight years at this point. 

The solution is usually stable. We have problems with space on the Rabbit servers. When they are full, we might lose everything. That's a big no-no. This is a problem for Kafka as well, however, we have higher thresholds in that area. Rabbit is the poor brother to Kafka, so it receives less space. That's why, sometimes, in some departments, this problem occurs.

The solution can scale, however, we use a lot of space for Kafka. We have clusters through the servers, and there may be more for each department. If some needs appear, we can increase the number of servers in a cluster to better manage messages. As long as your company can increase the number of servers, it can scale. 

We have about 100 departments that use this solution in some way.

In our case, we have in our department five people and we have two clusters with Rabbit for two different directions. For us, it's enough. We do not plan to increase usage.

I've never directly contacted technical support. We use recommendations on the site, which is very good. I appreciate the recommendations, however, I'm not sure about the maintenance of the documentation from one version of Rabbit to the other. The older versions of the documentation might be less accurate.

Other departments might use, for example, Kafka, however, I'm unsure as I have no visibility on them.

I was there when the solution was initially implemented and, from what I recall, it took half a year. 

It was completely new. No one knew anything about it. However, we knew that we had to do something to improve the communication between departments. It was a good solution. That said, it took a long time before everyone understood how it works.

We had a few dedicated people who liked the idea of Rabbit and implemented it. It took a while for the rest of the company to get behind them and learn how to do it.

There are one or two people at any given time available to handle any type of maintenance responsibilities.

We handled the implementation process ourselves. 

We're using a few different versions. It depends on the department. Some departments have the latest, some don't, some use a very old version. I'm using 3.8. We do have plans to make an upgrade. 

It was a few years ago now when I learned this process of separating publishers versus consumers in terms of messages and communicating between departments. This was the biggest game changer for myself. I'd advise new users study that aspect and understand it.

I'd rate the solution at an eight out of ten. It's a very good tool and we use it all the time.

We use it for data warehousing.

For complex queries, which would normally take a long time, and for reporting, it is very efficient. It doesn't take a long time for the execution of any report for the end-user.

• It's one of the fastest databases in the market.
• It's easy to use.
• From a maintenance perspective it's a good product.
• The segmentation, or architecture of the product is different than other databases such as Oracle. So even in 10 years, the data distribution for such segments will not affect other segments.
• The query performance of the product, for complex queries, is very good.
• It has good integration with Hadoop and Big Data.

The implementation of an upgrade takes a long time. But maybe it's different from one instance to another, I'm not sure.

Also, one of the disadvantages, not a disadvantage with the product itself, but overall, is the expertise in the marketplace. It's not easy to find a Greenplum administrator in the market, compared to other products such as Oracle. We used to work with such products, but for Greenplum, it's not easy to find resources with the knowledge of administration of the database.

If we face any issues they're normal and we open tickets.

It's scalable. I would rate scalability seven out of 10.

We hired one DB admin for Greenplum. If he faces any issues he opens tickets with the vendor, but most of the issues, 90% of them, he is able to solve without support.

We used to other products before, but when we worked with Greenplum, as compared to other products on the market, we found it's a good product.

Before Greenplum, we used Oracle but it was mostly obsolete. So we had to upgrade our tools. We needed to have a database with an API tool.

I'm not a professional in the setup but setup of the environment itself was managed by us. We managed between development, testing, and production servers. We are able to maintain it. I don't think it is complicated.

Most of the issues can be solved without referring back to support. A very small minority of issues required support from the vendor.

Pricing is good compared to other products. It's fine.

We did a comparison among some databases, one of them Greenplum. We assessed features, did a comparison in terms of the price, then we chose Greenplum. And we've retained it. We've found it's a good product, to date.

Oracle Exadata was part of the comparison, as was IBM Netazza. In terms of quality and the price, compared to the other products, we chose Greenplum. Also, to be honest, at that time we got a good offer: Use it for the first year with a minimal price. Then they opened a support contract with us, later. That was one of the advantages.

I give it an eight out of 10. To bring it up to a 10, they need to interact more with customers. They need to explain the features, especially when there are new releases of Greenplum. I know just from information I've found that it has other features, it can be used to for analytics, for integration with Big Data, Hadoop. They need to focus on this part with the customer. 

Also they need to enhance integration with other Big Data products. They need to adapt more, give more features, because customers are looking for these things in the market now. They have the product itself already, but they need to integrate with Big Data platforms and to open a bi-directional connection between Greenplum and Big Data. They need to focus on these features more.

But, from my perspective, for what I'm looking for, I can say it's a good product. Most of the features I'm looking for are available.

We use RabbitMQ for tasks that need to communicate in real-time. I have used it as a microservices message broker.

The most valuable feature is that it's really customizable.

When you have simple tasks, it is easy to use.

When you have complex tasks, RabbitMQ is hard to use.

There are several things that you have to do manually, so there should be better tools for that.

I began working with RabbitMQ several years ago.

I have had no issues with stability. It has been perfect.

Scalability is not a problem.

Because we are using the open-source version, we do not use technical support and have been solving problems on our own.

The complexity of the setup depends on the scope of the implementation. For a single node, the initial setup is very easy. On the other hand, for setting up RabbitMQ with a cluster, you really have to know what you're doing.

We are using the open-source version, which can be used free of cost.

My advice for anybody who is implementing this product is to learn the concept of message queuing and study the AMQP 0-9-1 protocol. If you study this then you won't have any problem learning the system and working with it.

In summary, this is a good product that I will continue to use, and I recommend it.

I would rate this solution a seven out of ten.

Strong integration with Greenplum Servers.

Loading data to Greenplum server after batch processing.

6 months

Yes, issues with HA and issues in syncing with the Greenplum.

You cannot expect a split second response.

On a scale of 10 I would rate it as 7

On a scale of 10 I would rate it as 8

This has just been used for POC period not for a regular use.

Initial setup works absolutely well. We were using with only Greenplum.

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.