VMware Tanzu Data Solutions Reviews

We have two use cases for Tanzu; the first is for deep archiving where we're archiving a lot of data in petabytes and the second use case is for complex financial analytics for the regulators. We are customers of VMware Tanzu. 

Tanzu has cut our expenses because it doesn't use expensive hardware. We can store huge amounts of data in a single place and query that data quickly if regulators want to see older data. Carrying out large-scale analytics on a cheaper platform and getting it within 30 seconds is not easy. Tanzu helps us to achieve that. 

The optimizer of the product is very efficient and the solution has a good data retention policy. Greenplum has good data analytics features and provides good monitoring tools. 

I think the cloud version of VMware is still lacking significantly because we are using Snowflake or Redshift on the cloud. We have a lot of on-prem use cases and Greenplum is good for that but we also have a lot of cloud use cases and the solution is lacking in that sphere. A cloud-native version of Greenplum would simplify things by enabling the move from Greenplum to Greenplum. 

It would be helpful if they could include some inbuilt machine-learning functions for complex use cases. I'd also like to see some kind of integrated dashboarding within the product for visualization. For example, Power BI integration or Tableau integration so that we could create a quick dashboard without getting Power BI onboarded.

I've been using this solution for six years. 

The stability could be improved - we sometimes have to deal with disk outages. 

Once you create a box of, say, five terabytes, that's what you have. Moving to 20 terabytes means creating a new box. You cannot scale at will. We have over 1,000 users that include data analysts, business users, management, and data engineers. We don't have plans to increase usage. 

The customer support is pretty good. 

Neutral

We previously used Teradata which is a much better product but it was super expensive, around five times more than Greenplum. We had other reasons for moving to Greenplum including the super fast analytics it provides. 

The deployment is reasonably straightforward, it takes at least a month or two because of the hardware. There were around 10 people, primarily data engineers, involved in the implementation and it was all done in-house. Two people are responsible for maintenance, they are DBAs for tech backup.

Licensing costs are very, very reasonable and I don't believe there are any additional fees. The hardware is inexpensive.

If you have a data warehouse use case for complex analytics on terabytes of data, without the need for real-time data, and you can wait an hour or two for data coming from source, this is a very affordable product that provides reliable service in a consistent way. The product requires minimal maintenance and support, without any need for supervision. Once you design your system, it's very easy to onboard all your queries quickly. 

Although this is a cheaper solution, there are issues with stability and scalability which is key in today's world, as is cloud compatibility, so I therefore rate this solution seven out of 10. 

Postgres is a database. Like Oracle is a database, this is a database.

We replaced our Oracle paid database with the open-source Postgres database, and we migrated around 50 lakhs of consumer data there with different rows and tables. We deployed this in different production staging and testing. We created three deployments, and each deployment has three servers.

Earlier, we were using the Oracle paid database, which is a commercial product. Then we switched to open-source due to the fact that we have lots of new projects and we could not handle the licensing costs. So we migrated our data from the Oracle Database Server to the Postgres Server. It helped us to evaluate the cost. We saved lots of money in terms of licensing.

It is open-source.

It provides the database load-balancing capability itself. It has data, like Pgpool, an open-source database, and a load balancer also.

We can also create the cluster in between the database in active, standby mode.

The solution is stable.

It's scalable. 

It doesn't have any GUI-based monitoring tools. Oracle has some proprietary tools for monitoring all the databases and all that. Postgres doesn't have any graphical capabilities where we can monitor the database. We have to do it with the Sierra stuff and run some random commands. Then we can get the data from the cluster and databases table.

The initial setup is complex. 

It would be ideal if they could provide an active cluster in Postgres. If one primary DB goes down, it should automatically fail over to the second database.

We've been using it for four years. I've used it since around 2018.

It's stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

It is very scalable. 

From the user's perspective, we have around 500 users. However, we have around 50 lakhs of consumer records in the solution.

We plan to increase usage. We already added the sponsors, and we require the capacity and the transactional processing. Therefore, it's scalable. We don't have any licensing restrictions, so we can add on as required.

While we don't have technical support, we do have creative support. They are quite good.

Positive

We used to use Oracle Database.

We required lots of planning during the initial setup. The migration phase is very complex when you move from Oracle to Postgres. The installation and configuration have a moderate amount of difficulty.

The deployment and maintenance require three people, including one system administrator and two database administrators. 

We handled the initial setup in-house. We didn't need any outside assistance.

We haven't invested any money into the solution and therefore haven't looked into ROI.

We have zero licensing costs. The solution is open-source.

We also evaluated some parts of MySQL. However, we didn't find it very suitable and scalable.

You need to be clear about your use cases and the transactional requirement you are observing from the database architecture before beginning with this solution. You need to consider your architecture based on the scalability and reliability of the applications. You need to take this into account before deploying any solution to Postgres.

I'd rate the solution eight out of ten.

We were using it as a high-volume text messaging solution. 

It's fully open source, has a high throughput, and the serviceability is good.

This solution struggled with multi-regional synchronization.

The stability of this solution was very good. 

The scalability was good. It's very comparable to the other databases on the market. We were doing 5,000 transactions a second, and probably one third of those were unique users at any one time.

The tech support was fine. We rarely needed to use it. 

The setup was pretty straightforward, just standard database install stuff.

For maintenance, we had a single DBA, and a couple of people on our software development team served as their backups.

On a scale of one to five, with five being the most competitive pricing, I would rate this solution as a four. 

We were using SQL Server in some circumstances, and the two solutions are very comparable, other than one being open source and one not. We've also used Cassandra, Bitquery, and a whole bunch of others. Each solution has unique advantages and disadvantages. From a feature standpoint, this solution is relatively close to parity in the environment. It stands out because it's opensource and cost effective, and it does everything pretty well.

For those looking into implementing this solution, my advice would be to think about how you want to handle multi-regional replication.

I would rate this solution as an eight out of ten. 

We use the solution for the asynchronous call and POPS mechanism.

The most valuable feature is asynchronous calls, which are easy to configure.

We needed to configure additional plugins. While it was relatively easy to do this on-premises, it became more challenging in the cloud.

I have been using VMware RabbitMQ for one year.

The product is stable. We haven't faced any issues.

VMware RabbitMQ needed to be a more scalable product. It wouldn't perform consistently if you wanted to add workload or users or reduce workload. We faced problems with it during heavy loads. The cloud version is scalable. We can scale it up or down based on our requirements, such as the number of users or workload.

Around seven or eight people were in every group, and many teams were using it for virtual use.

The infrastructure was handled by a person responsible for configuration and related tasks. I primarily focused on configuring connections as a developer. I could handle it by installing components like plugins. When issues arose in the cloud environment, we escalated them to the support channels.

We installed VMware RabbitMQ on a local computer. We are currently using Docker and Kubernetes for deployment in our local environment. It was relatively easy to deploy compared to an on-premise system.

The solution can be a bit challenging to handle. Not every configuration and deployment works seamlessly. It depends on the project team and compatibility, but is relatively easy to use.

The product is free of cost.

We configure the monitoring and alerting for the RabbitMQ setup. We transfer the message to the designated queue if there are any errors or similar issues. We use a Spring Boot application and microservices for this purpose, making it easy to route the message.

If you want to use this solution, you first need to understand the concept of exchange queues. Certain clusters require specific knowledge. The configuration may vary depending on the application type. For instance, the configuration was relatively straightforward in our case with microservices. We only needed to provide authentication and the correct URL. If it ran on a cloud environment, we would provide the instance, username, and password, and the configuration would be handled automatically. It would depend on the language and the specific type of microservice or application for more advanced customization, such as writing code.

The solution is easy to use, configure, and install.

Overall, I rate the solution an eight or nine out of ten.

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.

We can use the solution to move large amounts of data. Most of the functions have to be done manually.

The features of the solution are similar to Anypoint MQ. The transaction of data is pretty fast. Large amounts of data can be moved pretty fast using the solution.

The product is pretty hard to configure.

I have been using the solution for almost a month.

I rate the stability a seven and a half out of ten.

The tool's scalability is similar to that of Anypoint MQ.

The initial setup is complex. The product is deployed on the cloud. The configuration and setup are pretty complicated.

I use my own server and deploy the code with Jenkins.

It is an open-source product. We have to pay for additional features.

The configuration and setup of Anypoint MQ are easier.

People wanting to use the solution must learn how to configure and deploy it. If the documents are pretty clear, they will be easy to use. Overall, I rate the solution an eight out of ten.

The product's feature of data transaction works fast.

VMware RabbitMQ's configuration process could be easier to understand.

We have been using VMware RabbitMQ for a month.

I rate the platform's stability a seven and a half out of ten.

The initial setup is complex. It is difficult to find any documentation explaining the process. I deploy the code on the server using Jenkins.

It is an open-source platform. Although, we have to pay for additional features.

I rate VMware RabbitMQ an eight out of ten. You should know how to configure and deploy it on the servers. If they provide good documentation, it will be easier to use.

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.