Vertica Reviews

Two of them:

• The core feature, meaning their highly efficient columnar file format and execution engine along with a great coverage of ANSI SQL, provides our analysts with a highly expressive and performing platform.
• The extensibility and efficiency provided by their C++ SDK.

Before Vertica, we used a combination of sharded RDBMSs and Hive: the typical runtime for a query was in the hours. It's now in the seconds, with way
more data than then (we're talking hundreds of terabytes).

Whatever's out, the core is not always as great as the engine, especially their first version. That's true, for example, for the Kafka or Hadoop integration.
But they're getting better release after release.

Four years.

Vertica's code, being designed to use the hardware at its maximum, is very sensitive to low level changes such as kernel bumps or GLibC upgrades. It's also important to do tests on the storage layer (RAID controller + disks).

The default layout (all nodes running spread) introduces latencies in query planning when you reach about 60 nodes, in our experience. Switching to a large cluster (one control node per rack) would be advised, way before reaching the 128 nodes hard limit.

It's really great. One of the best I had to deal with. They also assisted us during the development phase of the custom components we've designed.

Not really in the same area (MPP databases). However, we ran benchmarks back then against a bunch of competitors and Vertica was one of the fastest, while
being relatively cheap and able to accommodate our hardware.

The setup per se was pretty straightforward. However, it took us some time to design the most efficient loading pattern from Hadoop.

Nothing to advise really; try it out first, it's free up to three nodes and 1TB, and then get in contact with their sales guys.

We did evaluate mostly SAP HANA and SQL Server PDW back in 2013, along with a bunch of OSS solutions.

If you plan to use Vertica for different workloads (in term of IO patterns, query frequency, dataset structure) plan to split your clusters: the mother of all cluster patterns becomes quite difficult to manage at some point. We today have around 20 clusters for different usages.

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.

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.

Fast inserts, queries way faster than in SQL Server.

Certain research which was unattainable beforehand, now is in reach.

Some GUI Tools out of the box, better python integration. I would love to see some nice query engine, tooled specifically to Vertica extensions of SQL (with IntelliSense). We currently use TOAD, but it has a lot of bugs and does not provide full support of all Vertica features. For example with the "copy to" command it is buggy - extremely hard to debug.

Other issues would be better query plan display and better management tools like command line admin tools. (MC would probably solve a bit here, I saw a demo on the conference). We have several avid Python users in the company, but this how maybe lower priority after I reviewed my conference materials and found that Vertica now has native Python driver.

2 years.

I was acting as my own DBA for a while, so a lot of hurdles before. But things are getting easier as more people in the company bought into the solution. I also got HP Training in house. (Thanks Herb!)

We can scale a lot, wish it was a bit more affordable.

It complements our SQL Server solution.

Own efforts.

Switch to per node from per TB.

Super-fast aggregated results from massive data.

We can process vast amounts of data, fast and with a high degree of reliability.

Better feedback from installation. I would like to see more meaningful errors returned and more graceful handling of those. Thankfully, we don't often hit error conditions.

4 years.

No

No

Depends on the environment. Generally pretty good. If you have a large catalog, you can get timeouts adding nodes. Large catalog issues have been dealt with it recent releases so this should make scaling up even more robust.

Excellent. It can take some time to get to the right people but generally our issues are all addressed in an acceptable timeframe.

Greenplum. It was less stable.

Vertica is very robust and recovers predictably from unexpected infrastructure failures.

Great overall solution.

Geospatial

Profiling, query optimize, management.

1 year

Some bugs, they were rapidly fixed.

Minute

Not yet

Excellent

Very good

SQL Server did not scale.

Recovery by table

Copy cluster

VBR backup used to take more than one week to back up 70 TB of data. After upgrading to latest version, it is taking about 48 hours.

Improve Vertica logging and messages to Vertica startup commands.

4 years

I'm a Vertica specialist, and I'm certified by Micro Focus. The solution is deployed on-premise, but we have another installation on the cloud for another client.

It's the fastest database I have ever tested. That's the most important feature of Vertica. It has a lot of contents and machine learning functions. Today we have a lot of options for deploying. It has a lot of integrations.

I think they need an easy client so that you can write queries easily, but it's not necessarily a weak point. I think some users would need them.

In other versions of Vertica, there is a lack of integrations in some machine learning models. But today, the latest version has it all. I don't think they need too much improvement in that area. For me, it's great considering the use case I work with.

I have been using this solution for four years.

I haven't really had the opportunity to talk with them, but that's because the database just works. I don't really need technical support for maintaining and running the database. The documentation is very clear too.

The pricing depends on the license model because there are several. It depends on the client, but it's cheaper than other solutions. I think it's cheap for all the functionality and robustness. It's not very expensive to deploy.

I would rate this solution 8 out of 10. 

People should be careful with the way they are loading their data because Vertica is very fast at copying data. There are some operations that are slower than Oracle or SQL Server, but normally you wouldn't use that.