VMware Tanzu Data Solutions Reviews

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 are using the product for analytical purposes like reporting and billing.

We maintain the servers on our premises. Compared to Snowflake, Greenplum is a cheap solution for analytical purposes.

The latest version is better than the older ones. The solution updates very fast. The loading speed is very good.

Maintenance is time-consuming. It takes time to VACUUM and ANALYZE the tables to remove the fragmentations.

I have been using the solution for five years.

The solution is stable.

Compared to Snowflake, Greenplum is not scalable. The solutions used on premises are not scalable compared to the cloud solutions. Around 200 to 300 people use the product in our organization.

Support is fine. We do not use high-level support. The support team is quite supportive.

The setup is easy. It is not complex.

We must set up the instance and run scripts to deploy the product. It is very simple. We can deploy the scripts with one or two commands. One person is enough to deploy the solution.

It’s an open-source solution. There are no expenses for using it.

We are using the latest version of the solution. Some of our clients asked us why we were not using Snowflake, so we are evaluating Snowflake as per their request. If we replace Greenplum with Snowflake, the purpose would be to minimize maintenance time and enhance scalability. If someone is looking for a cheap solution, Greenplum is a good choice for them. Overall, I rate the product a six out of ten.

We specifically use the solution for queuing purposes, and it has proven to be fantastic in that aspect.

The solution's best feature is its exceptional speed, delivering efficient utilization of resources. It uses a memory desk processor very efficiently. It offers high performance while maintaining a low cost.

The solution is a fine product. However, to make it perfect, in some cases, there might be a need to traverse the queue. RabbitMQ currently lacks the capability for archiving the queue, which essentially turns it into a log.

For such requirements, you may need to explore other options like Kafka or custom drivers that allow traversing the entire queue. In RabbitMQ, while you can traverse the entire queue, you need to devise a workaround to handle the messages. For example, you can read a message from one queue, publish it to another queue or keep it in some other way to retain the desired entries, and then stop at that point.

Additionally, the need for support may vary depending on the usage and potential heavy loads on the system. The support feature could benefit from some improvement in terms of accessibility and responsiveness.

I don't encounter significant challenges or areas that require improvement while using the solution. Everything works smoothly, and I find it well thought out. It's got excellent compliance with MQP 9.0. Overall, I have had a positive experience with the solution.

I have been using the solution since 2017.

The solution is highly stable. As an example, at this moment, I am in front of my admin panel and can confirm that it has been running continuously for the past 173 days.

The solution is scalable, although I still need to utilize the clustering option. A single server is sufficient and efficiently handles most of our workloads. It effectively uses system resources such as memory, CPU, and disks, resulting in excellent performance with minimal resource usage.

So far, we have not needed any support from the solution's official support team or community. We rely on Google search and our team's research, leveraging various online resources to explore and implement solutions independently.

When I joined my current company, I initially explored Apache Kafka, but I realized that Kafka is primarily a log system rather than a queuing system. I encountered limitations with Kafka, such as maintaining pointers for each process and manually removing messages from the queue.

Comparatively, RabbitMQ proved to be more convenient as it automatically deletes messages from the queue when using auto or manual acknowledgment. Considering these factors, we switched from Kafka to this solution due to its efficiency.

The solution's installation process was straightforward, especially if you have good skills in installing software and a good command of Linux. Once the Bandit software is downloaded and extracted, the installation is completed.

After that, accessing the admin interface allows for a user-friendly GUI experience. The deployment process took around half an hour. 

We have a private cloud infrastructure using VMware, which means our servers are running on-premises and are owned by our company. We have a limited number of servers running the solution.

Specifically, we have one primary server and one secondary server without implementing clustering. Replicating these two servers is sufficient for our workload, and they can be installed by a single system administrator in just half an hour without any issues, provided they have DPU-installed Linux available.

Overall, I would rate the setup experience as nine out of ten.

The solution's pricing is cost-effective as it does not involve significant expenses. Licensing is required only for the server, while clients do not need any licensing. Therefore, it proves to be a cost-efficient option.

In my previous organization, we heavily relied on Tibco messaging solutions like Tibco RD (Rendezvous) and Tibco RV (Rendezvous) for the entire rating system. I have also explored Apache Kafka.

If you are looking for a queuing system for your application that guarantees insured delivery and ensures single delivery without duplicates, RabbitMQ is the right solution as it provides all these capabilities with ease of use.

With RabbitMQ, your application doesn't need to worry about receiving duplicate messages as the solution handles that internally, ensuring that each message goes through a single process for one delivery.

I highly recommend the solution and would rate it an eight out of ten.

Of particular value to our environment and applications are the following Greenplum capabilities:

1. Scalable (Massive) Parallel Processing (MPP) – The ability to bring to bear large amounts of compute against large data sets with Greenplum and the EMC DCA has proven itself to be very effective.
2. Fast load of data into Greenplum – We experience performance of approximately 1TB per hour loading data to Greenplum without the use of specialized hardware.
3. MADlib (madlib.net) – There are a number of statistical and analytical functions available within MADlib upon which we rely. Among these are linear regression, logistic regression, apriori, k-means, principle component analysis, etc.
4. User Defined Functions in Python (UDFs in PL/Python) – Where MADlib does not provide a direct solution to an application problem, the ability to quickly prototype and deploy user defined functions with Python has been effective.

We would like to see Greenplum maintain a closer relationship with and parity to features implemented in PostgreSQL. The current version of Greenplum is based on a fork of PostgreSQL v8.2.15. This edition of PostgreSQL was EOL by the PostgreSQL project on Dec 2011. The current version of PostgreSQL is v9.5.

We began production use in November, 2011. Alongside Greenplum, we're also using EMC Data Computing Appliance v2.3.3 (8/10), of which we have two and a half racks in production, and one and a quarter racks in dev/tests.

We had no issues with the deployment.

The only issues with stability we’ve experience have been the sporadic fail over of primary to mirror segments. The environment continues to operate in this instance with the failure of queries that were in flight at the time of the fail-over.

We have had no issues with scalability whatsoever.

The service and support we’ve received from both Pivotal and EMC has been exemplary. The exceptions to this would be:

1. The EMC Request for Product Qualification (RPQ) process – EMC DCA support is contingent upon EMC approval of all third party software installed onto a DCA. There have been times that this approval has taken as long as 60 days to process.
2. Root Cause Analysis of Greenplum Database Incidents – When Greenplum Database incidents have occurred (e.g. primary database segments failing over to their backup), and Pivotal has been called for support, the response has been near immediate (30 minutes or less). Additionally, the incident resolution provided has been equally expedient. Where this has caused some disappointment is the response to our request for a root cause of the incident. These requests tend to queue up and we don’t seem to get answers beyond the typical vendor response of “that’s been fixed in the next release”.

The purchase of Greenplum was our first interaction with Pivotal. We have been a customer of EMC for a very long time.

My primary reason for reducing points on this rating is due to the fact that Greenplum is based on a fork of PostgreSQL v8.2.15 (EOL by the PostgreSQL project on Dec 2011). The current version of PostgreSQL is v9.5. There are a number of current PostgreSQL features of which we would like to take advantage (JSON support, materialized views, full text search, XML support, column-based permissions, row-based permissions, etc.).

Greenplum is a distributed database that we used for data warehousing.

The parallel load features mean that Greenplum is capable of high-volume data loading in parallel to all of the cluster segments, which is really valuable.

The service management capabilities are good.

The external data integration with Parquet, Avro, CSV, and unstructured JSON works well.

It has an advanced query optimizer.

The initial setup is somewhat complex and the out-of-the-box configuration requires optimization.

- OS settings need to be tuned according to the Install guide.

- Only group/spread mirroring by gpinistsystem, block mirroring is manual (Best Practices Guide)

- Db maintenance scripts are not supplied - some of them added in cloud - need to be implemented based on the Admin Guide.

- Comes with two query optimizers, PQO is default, some queries perform better with the legacy planner, it needs to be set.

We have been working with Greenplum for about five years.

Greenplum is pretty stable.

This product is absolutely scalable. We have more than 400 users in our database.

The technical support is exquisite.

This is a company that really listens to its customers. I am very happy with our relationship.

Before I joined this company, I used different data warehousing solutions.

Making the transition to Greenplum requires a completely different mindset because it is massively parallel. It's more like a Big Data mindset, where you need to consider that you are distributing data between cluster nodes. It is not always straightforward to make the switch.

The initial setup is kind of complex. You need an expert to set up a Greenplum cluster.

It may not be possible to simplify the initial setup because there's an out of the box configuration and you can use it. I've actually seen companies using it for years and it works, but it didn't work optimally so they were not happy with the results.

You can set up Greenplum but you really need to read the manual and the installation guide. I've seen people skipping it and then complaining.

A few people are enough to maintain this product. If you want to have around the clock support then you will need a couple of people in different time zones, but generally, maintenance is straightforward.

We are currently in the process of upgrading from version 5.26 to 6.11 and I can already see a lot of improvements. I can't wait to try them. According to the roadmap, there are a lot of new improvements coming in the V7 version, which is due out next year.

My advice for anybody who is implementing Greenplum is that they really need an expert to assist them. They might hire consultants or grow experts in-house, although that takes time and it is not always straightforward. You can use Greenplum out of the box but to really leverage all of the capabilities, you definitely need to tune your system and also design your database objects.

When people think about a database they usually think about Oracle, Mircosoft SQL, or maybe MySQL. Greenplum is a distributed database that needs a completely different mindset. I think that when people start to use it, they don't really understand. For example, you cannot switch from Oracle to Hadoop because you will need the same change, but when they switch to Greenplum from Oracle, or just put data from Oracle to Greenplum, they don't consider this change as seriously as they would for Hadoop.

Overall, I am very happy with this product.

I would rate this solution a nine out of ten.

I've found that the data compression and ETL are the most valuable features for us.

In 4.3.8.1 Pivotal confirmed that even restoring schema level backup is possible from a DB backup.

- restoring schema from a DB level backup has been tested and working fine .

ORCA - the Pivotal Optimizer does a good query plan but does not works with all business logics. This needs to be tested based on your requirement.

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

Running Extracts has drastically improved the timings. Being MPP which is a bulk operator - we were able to do 1.5 million calculation in 15 minutes.

Scaling of the solution needs to be improved.

HD connection is available where as, not to any file system.

Connecting Greenplum with Gemfire(In-Memory) to load, sync, and reconcile data would be really valuable.

I've used it for nearly for 3 years

We had deployment issues after installing new patches. Every new patches has some or other business hit where the release notes needs to be reviewed.

It's been stable for us.

They have a quick turn around but to dig into the actual information takes time, based on the Severity.

First level of technical support would not be that effective (based on own observation).

We were using Sybase and handling massive data, bulk operation was not possible.

It was simple.

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.

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.