VMware Tanzu Data Solutions Reviews

Processing speed of queries used for ‘Reporting’ solutions is the most valuable feature.

Not Applicable for the area I was responsible for, as we ended up migrating away from Greenplum.

Stability and scalability for large number of concurrent applications & their users. The results we got were very inconsistent, depending on number of connections taken up by multiple applications and users.

When our application was first deployed using Greenplum, the number of users of the rrack on which Greenplum was deployed was very limited. We got excellent query performance results at that time. But as more applications started getting deployed, we started getting very inconsistent performance results. Sometimes the queries would run in sub-seconds, and sometimes same queries would run 10 times longer. The reason we found this was that Greenplum limits the number of active concurrent connections. Once all connections are being used, any new query gets queued, and thus response time suffers.

The impression we got was that the EMC Sales team that sold Greenplum to the organization did a great job. But later on the ball was dropped when it came to educating on which type of applications are suitable to Greenplum , and how to configure it to get optimal performance. When Pivotal took over support of Greenplum, their consultant visited us to go over the issues we were having. He advised us that Greenplum is not the best environment for our application needs. We ended up migrating our application out of Greenplum, along with a few other applications.

There was no issue with the deployment.

There were issues with the stability.

There were issues with the scalability.

Ensure that this is the right tool for your needs. For instance, Greenplum is not the best tool for cases where data has to be kept up to date in real time. Capacity planning is key to success, once you do decide it is the right tool for you.

• Distributed data for performance
• File loaders to reduce dependency on Informatica

Batch processing times have dramatically decreased from over 12 hours to under three hours. Much of this is converting off of Informatica and using distributed processing. Reporting performance also improved greatly.

Since we are upgrading to a new version at this time, it’s hard to say. But we seem to be replacing a disk on the appliance every week.

I've used it for six years.

There's no issues, although we are currently in the middle of an upgrade to v4.3.5.

It seems like we are replacing a disk on the appliance every week. Not a noticeable issue for users and batch processing is not adversely impacted.

Very good. Response times are good for service calls.

I believe the set-up was straightforward. I don’t remember any issues.

We used a vendor team. My advice is that the planning is critical. When converting processing jobs, convert them to PostgreSQL for better performance. Yes they could work as written previously, but you benefit using the features of the product immediately if you adjust the processing to match appliance. Use the bulk processing to your advantage.

We evaluated other solutions. Not sure of the reasons why this product was chosen.

It’s a good product. We moved from Oracle and I don’t want to go back.

The Greenplum loaders – their methods, insert, update and merge – were most valuable. The external table feature within Greenplum was also very valuable in achieving performance and scalability

A lot of customers use Greenplum and for their ETL use cases they use Informatica PWX for Greenplum, which helps them achieve transfer of data from a number of data sources into Greenplum. We can help customers to load data effortlessly and quickly.

It would be best if Greenplum would support array writes through ODBC drivers . Currently through Data Direct Greenplum drivers we can have single row inserts into Greenplum only. It would help if array loading is supported.

I have been using Greenplum loaders to load data into GreenPlum for three years.

There were no issues in deploying it.

The external table feature helps to make this a stable solution.

It scales to our and our customers needs as required.

The ongoing response from their support on certain technical issues has been slow. It would help if we can have a faster turn-around here.

There was no other solution used previously.

The installation and configuration is straightforward.

We implemented through a in-house team . The overall solution will be useful and is not complex

If the use case is going to be requiring a huge data transfer and big data analytics. This is a good product to use.

• Parallel processing
• Takes minutes to process millions of records

This has improved our daily load process reducing the run time at least by three to four hours which made other departments within the organization to look for data from the Enterprise Data Warehouse.

It acts like a mainstream product not a novice any more. There are a lot of areas that can be improved. The bug fixes come as many patches like a start up instead of having scheduled release with proper improvements.

I've used it for five years.

It took a while to fully take advantage of this as we had to come up with lots proprietary solutions when linking to other products.

There is no issue with its stability.

There is no issue scaling it.

8/10 we had a technician come out on a new year in 2012 to fix some hardware failure.

We were one of pioneers in adopting this solution. So we got the best deal when compared to the competitors in several areas.

The initial move was a bulk transfer from the old system to new Greenplum based solutions. It was all done by Greenplum contractors. But to get it working with other products was challenging.

Greenplum employees developed and supported the initial move. Later they became remote consultants with support through phone and in-person as needed.

They gave a really good deal and we have been with them for five years even though the product got bought over by couple of different companies.

You need strong DBAs and architects to support the initial transfer.

MPP (Massive Parallel Processing); processing large amount of data.

We process billions of rows of data every hour; MPP architecture is important to process data in such volume.

• Better integration with big data tech stack
• Scalability: for example, system schema (pg_catalog) is one bottleneck for scalability

I've used it for four to five years.

The system has some bottleneck, like system schema; some commands (batch loading) is bottlenecked by master DB architecture

It's very poor.

It's very poor.

Used Greenplum originally. We have evaluated other products; the final decision is based on ROI

Products was installed by vendor; all ETL scripts and schema are designed and implemented in-house.

The product was installed by vendor; all ETL scripts and schema are designed and implemented in-house.

Greenplum has an open source version now.

Scalability is one major concern; once data reach certain level; the performance is dropped and much more issues will be triggered, like disk error; out of memory; etc. Be sure that you proper scope your need (including growth) before the decision of system and its size.

The MPP – fast aggregation and that I still reuse the PL/SQL code.

The reports are running very fast, a matter of minutes instead of hours as it was previously.

It should support more feature that do exist on Postgres – like JSON datatype.

I've used it for three years.

Not more than any new DB – not something particular.

Not more than any new DB – not something particular.

Not more than any new DB – not something particular.

It's good.

It's good.

I used Oracle Enterprise edition – moving to Greenplum due to the MPP (it’s like Map-Reduce). I prefer a SQL solution rather Hadoop or whatever – especially if you’re moving from RDBMS. Now I’m also using Amazon Redshift from the same reason and also we don’t need to manage any server, it’s only a service and this is our best option especially because we’re already using Amazon.

It's straightforward.

In-house.

Read the documentation and always perform tests.

There are many valuable features, such as parallel loading and the solution's scalability.

It's allowed us to do a lot of data analytics with it that we weren't able to do before.

The performance needs to be improved.

As a whole, two years on multiple versions.

We've had no issues with deployment.

It's stable, but slowness is an issue.

It's scaled find for us.

Customer service is OK.

Technical support is OK.

No solution was used previously.

Implementation was done by a vendor team.

Pricing is pretty much OK compared to others.

Processing speed – especially loading and transformation of large data sets.

Before we implemented Greenplum, our weekly data loads (for third party marketing data sets) were taking over three days. (We also had some monthly data that could take up to 3 days to load and transform via Informatica.) After we implemented Greenplum, the loads were reduced to less than nine hours. Previously, we were receiving data early Wed a.m. and not getting out to the salesforce (if we were lucky) until noon on the following Monday. Now we get the data to the field early Friday mornings before they wake up.

The Greenplum appliance itself has had some reliability issues, so it would be great if that could be improved in the next version. More critical, though, is that the latest devices are not backward compatible. i.e., We have to replace our entire environment to upgrade. That’s quite an expense. I would hope they could improve the upgrade roadmap in the future.

We have used EMC Consulting for some projects, and we have lots of EMC storage.

If you can, do a benchmark with other MPP options including cloud alternatives. Although our Greenplum implementation was very successful (going on 4 years ago), I wish we had benchmarked against Teradata and Netezza (now IBM) at least. Today, I would consider not even buying hardware… just doing it all in the cloud.