OpenText Analytics Database (Vertica) Reviews

Vertica is an excellent data warehouse platform. Its column-oriented architecture makes it a powerful database specialized for data warehouses. Data should be designed around a star schema.

Data is accessed via SQL, which most developers are already familiar with.

Vertica is "catching on" in the software market, so its user knowledge base is gradually increasing.

The price seems reasonable, the product is reliable, and it uses SQL, so developers don't need to learn a new language.

It provides very fast results for analysts running reports. These reports are crucial to help our clients strategize their targeted marketing.

Vertica is relatively new and needs some polish and refinement, but its core functionality is excellent.

Documentation overall is fair to good; but lacks continuity or cohesiveness in places.

Although its knowledge base is increasing, it is still relatively small, making some issues difficult to diagnose without consulting Vertica Tech Support.

Vertica does not have native stored procedures or a native scripting language. Instead, external functions (which can be called from within Vertica) using Java, C++, Linux shell scripting, etc., are supported. This is an unpleasant surprise for many developers, but I feel this has not been a big hindrance in my experience. Complex business logic probably does not belong in a high-performance data warehouse platform. Rather, this should be taken care of during ETL.

I have 3+ years of experience with Vertica.

Deployment had only a few minor issues that one finds with most software.

It has been very stable.

I would give technical support 8 out of 10. They have been responsive, professional and knowledgeable.

• I have used traditional, row-oriented relational databases like SQL Server, Oracle and PostgreSQL for data warehousing. They are optimized for handling transactions, not data warehousing. Vertica is optimized for data warehousing and that was very clearly demonstrated in its ability to scan large amounts of data at high speed. It is also very fast at loading data.
• Vertica uses a distributed, shared-nothing architecture which allows for nodes to be added (or removed) according to need. This is a very scalable architecture which is very difficult to achieve with traditional row-oriented databases.
• Compared to Hadoop, Hive, and Spark, Vertica is much more adept at handling concurrent users.

Installation is recommended for someone familiar with Linux (the only OS available for Vertica). For developers with a Linux background, the issues are very manageable. Documentation is good for the installation, so follow it carefully, step-by-step.

Implementation was in-house. No significant issues were encountered.

ROI is good because Vertica, while not cheap, is a better performer than traditional databases.

• Understand that its strengths depend on a good data warehouse design using a star schema. It was never intended for high volumes of small, randomly distributed inserts, updates and deletes that are typically found in transactional databases.
• It uses column-oriented architecture. It is important to study aspects of this architecture and to implement them and modify them as the database grows in size and more users access the system. This is especially true for projections, run-length encoding, sorting and column ordering. It is important to understand these aspects in order to truly maximize Vertica's performance.

It has a very good design with high query performance. It provides the scale out capability by adding additional servers instead of scaling up the servers.

It has provided much better performance than SQL Server for big data analytics.

I would like to see integration with the latest Hadoop ecosystem.

We have used this solution for three years.

It is usually very stable, but we occasionally see some nodes going down.

There have not been any scalability issues. We are able to support trillions of data elements by adding more servers.

The technical support is pretty good. I would give it a rating of 9/10.

We used to use MS SQL Server. It is good for data transactions, but it is not good for big data analytics.

It is pretty expensive, but it is worth it if you need the production capability that it can support.

We evaluated SQL Server and Teradata.

It is worth a try if you are looking to provide a high-performance, big data analytics database.

The most valuable feature in the solution is ad hoc data analysis. It improved the SLAs for our end clients.

There are some predictive analytics features that we might be using which we thought were part of IDOL, but it seems some are also already part of Vertica.

The stability is super good, especially when you scale out.

Before using Vertica, we used to have problems scaling out because we increase our customer base significantly each year. We have more than 20.000 clients now. Since we implemented the Vertica solution, it is much less effort to maintain scalability.

I haven’t used technical support, but the IT colleagues definitely have. I think they are rather happy with it. I haven't heard any complaints. It could be quicker sometimes, but that's always the case with big processes.

Previously, we were basically using an old school setup based on a relational database. I’m not sure which database management system it was.

The performance of the previous solution was no longer adequate to support the growth we were seeing in our business. Response times were up to 10-15 seconds on different queries. We needed to get that down to under a second.

Now we’ve moved to a real big data analytics solution.

I wasn’t involved with that, but I think that those who did it were happy with the support.

When we chose a solution, we were looking at scalability, maintenance, and ease of use. With Vertica, we can access big data using regular SQL queries.

We are evaluating storage and database solutions for an OLAP application with following requirements:

• Extract, transform and load high velocity and volume of a numerical data stream on a distributed system.
• Interactive (less than 20 sec latency) query performance for critical group-bys.

Vertica is superior to other solutions in query performance.

We have not yet integrated the solution.

Vertica’s resource demands for RAM and I/O during load and storage were challenging for our platform. They recommend reserving 40% of storage for Vertica’s internal usage. Lower I/O usage during load is also highly desirable.

The solution is not integrated into our product. We engaged in a PoC for 2-3 months in 2015 and put the evaluation on hold due to other project priorities.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

The level of technical support by the sales engineers during our PoC was excellent.

Well-organized, online documentation made the initial setup fairly straightforward.

Our in-house team worked on the PoC.

We evaluated a number of open-source and proprietary databases, as well as an in-house solution. Our PoC has been put on hold and we have not made final decision on a solution.

The auto-distribution to all nodes for fault tolerance and query performance was pretty amazing.

Our data warehouse at the time was a multi-terabyte PostgreSQL cluster. It worked really well, but we wanted to increase the size to many TB's and our due to our query and loading patterns we found greater performance from Vertica's multi-node warehouse.

In the versions I worked with, if a majority of the nodes were being loaded under heavy, sustained rates the nodes would see some dramatic decreases in performance due to the data shuffling that needed to occur between all the nodes. To work around that we ended up doing most of the loading in one or two nodes and that helped significantly.

The synchronizations problems occurred when loading about 10 billion events, at a rate of about 100k tuples/second/node across 5 nodes. One of the suggestions from Vertica engineering was to increase the number of nodes to offset how much data was being sync'd per node.

Extensive use of Vertica 5 as a production datawarehouse, and a POC for a client.

In earlier versions Vertica, it could sometimes be a pain to install on multiple nodes. In the most recent versions most of that pain has been fixed. Stability in earlier versions was compromised at times when the majority of the nodes were under heavy write loads.

The service and support from Vertica was excellent. Every tech and sales rep I dealt with was very responsive, pleasant, and helped me solve any engineering issues we ran into in very short order.

I have used Greenplum and Postgres extensively. The latter is an excellent general-purpose database and is entirely suitable for most data needs, however Vertica works really well in cases where you are storing and querying a lot of data that can be compressed and stored in columnar format, and you need your data auto-balanced across many nodes.

The installation procedure was reasonably straightforward, but earlier versions of Vertica were a bit more tricky due to libraries and dependencies. The docs were unclear in a few places during the installation, particularly with OS' that were not fully compatible with the required libraries. I expect those issues have been resolved in the newest version (8 at this time).

Implementation was done in-house, with excellent support from the Vertica engineers.

My advice is to clearly define your expectations, and benchmark performance in real-world-like environments. If you expect to be executing 100 queries per second and loading 10 million tuples per minute, then test that, and test several times that so you collect measurements about where the system is liable to break down.

The compute and processing engine returns the queries fast and let us use our analysis resources in a better utilization.

The concurrency got better in this version and we are able to run more queries and load concurrently.

We built an internal dashboard using the MicroStrategyto increase visibility to our management and our employees. Also, we built tool to expose the data to our selected partners and users to create better engagement with our platform.

• Loading times for “real time” sources - for example, loading from Spark creates a load on the DB at high scale
• Connectors to other sources such as Kafka or AWS Kinesis
• Better monitoring tools
• Better integration with cloud providers - we were missing some documentation regarding running Vertica on AWS

We've been using Vertica for a year.

In case of one HD failure in the cluster, the entire cluster got slower. We feel that it should be able to handle such issues.

No.

The support was slow and didn’t provide a solution in most cases. The community proved to be the better source for knowledge and problem solving.

Pretty straightforward, the installation was simple and we added more nodes easily as we grew.

Vertica is pretty expensive, take into account the servers and network costs before committing.

We evaluated both AWS Redshift and Google BigQuery.

Redshift didn’t fulfill our expectations regarding query latency at high scale (over 60 TB). Regarding BigQuery, we found the pricing structure pretty complex (payment per query and data processed) and harder to control.

Don't plan a production usage on high-scale straight on Vertica, use caching or other buffers between the users and the DB. Get yourself familiar with the DB architecture before planing your model (specifically, make sure you know ROS/WOS and projections). Try to avoid LAP before your schema gets stabilized.

Columnar storage makes 'hot data' available much faster than a traditional RDBMS solution. Also, Vertica scales up quickly and maintains good performance.

Performance management of high-traffic sites - Vertica's ease of scaling has been invaluable for one of our main customers.

I'm concerned that HP Enterprise has sold their software business, and worry about future investment to enhance predictive/machine-learning capabilities.

3 years.

Not really.... Vertica shines on stability.

No, scalability is also a strength of the solution.

9 out of 10. HPE has some excellent engineers who are eager to help us make Vertica work well.

I've been a 'full stack' data expert for years, started on Oracle and SQL Server, moved to Hadoop, Mongo, etc, but Vertica was the right fit for large enterprises with high performance demands and ease of scalability.

Initial setup is a bit clunky, like most complex, tunable products can be.

Negotiate when their fiscal year is about to close :)

It's a solid product that keeps its promises. I do worry about HP Enterprise's sale of Vertica to Micro-Focus

Rating: 8/10 - it works very well, but some customers worry about 'Vendor lock-in'.

Speed in query in general and specifically in aggregate functions on multi-million rows tables.

Data Warehouse response times have decreased of one order of magnitude with respect to the previous solution (SQL Server + Oracle).

Sadly, it does not support stored procedures in the way we are used to thinking of them. There is the possibility to code plug-in in C++, but that's out of our reach. Correlated sub-queries are another point where we'd love to see enhancements, plus the overall choice of functions available. ETL with SSIS was not as easy as one we had expected (must remember to COMMIT and we had some issues with datetime + timezone, but that's was probably our fault).

OleDB and .NET providers need some touches; and another great improvement would be support for Entity Framework, which so far I haven't seen.

There is no serious graphical IDE for HPE Vertica, that's frustrating. One free option available is DbVisualizer for Vertica, but it's a bit basic.

One year.

We have a one node cluster on Red Hat and last week the DB went down. The setting to restart the database is not very intuitive and by default the DB does not restart alone.

After a reboot, which may be good in some environments, but leaves you with an insecurity feeling.

Our DB isin in the tens of Gigs, we did not need to scale yet.

N/A, not used.

We had SQL Server, switched for money reasons and space. But we're not sure yet, SQL Server is way more stable and predictable.

No, the documentation is scarce on non standard setups. We had to create a virtual machine locally, set it up and then upload it to AWS.

We use the free community license, plenty of space for our environment. If I had unlimited budget I'd buy a preinstalled instance on EC2, much faster, but costly.

Netezza, but I didn't like it. For no particular reason, but the feeling was not right. Redshift - I was not impressed by the performance. Google Big Query - we tried it.

Do COMMIT, and enable/enforce constraints because by default they ARE NOT!!!!

• HA Clustering
• Speed / Performance

We're able to retrieve queries nearly instantaneous for our custom analytical tools we built on top of Vertica.

More frequent updates.

1 year

None.

None.

Very knowledgable team which has provided excellent documentation for every issue we've had to troubleshoot.

MonetDB -- unstable, frequent crashes.

Straightforward, was able to get the database up fairly quickly with minimal effort.

We're still using the Community Edition (CE).

MonetDB, Cassandra, Amazon RedShift.

Great product, very mature and robust. Vertica is able to scale to meet our demands as we scale our business 10x.

The fact that it is a columnar database is valuable. Columnar storage has its own benefit with a large amount of data. It's superior to most traditional relational DB when dealing with a large amount of data. We believe that Vertica is one of the best players in this realm.

Large-volume queries are executed in a relatively short amount of time, so that we could develop reports that consume data in Vertica.

Speed: It's already doing what it is supposed to do in terms of speed but still, as a user, I hope it gets even faster.

Specific to our company, we do store the data both in AWS S3 and Vertica. For some batch jobs, we decided to create a Spark job rather than Vertica operations for speed and/or scalability concerns. Maybe this is just due to the computation efficiency between SQL operations vs. a programmatic approach. Even with some optimization (adding projections for merge joins and grouped by pipelined), it's still taking a longer time than a Spark job in some cases.

I have personally used it for about 2.5 years.

I have not recently encountered any stability issues; we have good health checks/monitoring around Vertica now.

I have not encountered any scalability issues; I think it's scalable.

N/A; don't have much experience on this.

We do have some pipelines accessing raw data directly and process it as a batch Spark job. Why? I guess it's because the type of operations we do can be done easily in code vs. SQL.

I would recommend using Vertica for those people/teams having large denormalized fact tables that need to be processed efficiently. I worked around optimizing the query performance dealing with projections, merge joins and groupby pipelines. It paid off at the end.