Vertica Reviews

Our use case is a typical data warehouse. We just use the data warehouse for reporting and the storage of data. Our users are the staff team who do the reporting and data analysis.

The feature I like best is performance. We use Red Tool and Red Job for the data warehouse and reporting. It's perfect. Performance is good, and it can return ad hoc queries very quickly. Of course, it's a cluster, so it's easy to scale.

It's hard to make it slow for a small data volume. For large volumes, it's hard to make it work. It's also hard to make it faster, and to make it scale.

I have been using Vertica for about five years.

It's a stable solution.

Vertica is a scalable solution.

Technical support is good, and they react quickly.

The initial setup is okay. You will need some knowledge and some training. I'd say learning takes a couple of months. We use one person to maintain the database side. With the DevOps team, everyone has a different role. But for our database, it's just one person.

The price is reasonable. We use a pay per license model. Firstly, you need to buy a license. After that, you mainly pay the annual support fee of around 20% or 25%. I think their prices are quite reasonable.

We tried to use data lake kind of stuff for machine learning, but for the key functionality of the data warehouse, it's great. Personally, I feel they are over-marketing the machine learning feature and for something like the semi-structured data. But for the data warehouse, it's truly a good solution. I want to recommend it highly.

I would tell potential users that it's hard to make it slow for small data volumes. For large volumes, it's hard to make it work, make it faster, and make it scale. Depending on your workload and your use case, you need to first purchase the Red Tool. After that, you need to follow the best practices to have an efficient design.

On a scale from one to ten, I would give Vertica a nine.

It enabled delivery of a new Agile Data Warehousing Service.

It enabled us to close large deals. Customers with large data sets had to be migrated from PostgreSQL to Vertica due to performance.

• Clustered database
• Horizontal scaling
• Disaster recovery
• Columnar Storage
• Compression (you read only columns you need)
• Immutable storage
• Fast ingesting

Performance of management of metadata layer (database catalog) needs improvement. We still have to have smaller customers on PostgreSQL; Vertica cannot manage thousands of schemata.

Query performance: Improve either Database Designer (automation of projection design) or performance of queries using suboptimal projection design.

Scaling of execution independently on storage: Upcoming Eon Mode (now Beta in Amazon) will hopefully solves this.

Encountered stability issues three times during last three years.

Suboptimal projection design causes queries to not scale linearly.

The metadata layer does not scale linearly.

Metadata for database files scale okay, but metadata related to tables/columns/sequences must be stored on all nodes.

I have experience with legacy vendors of enterprise RDBMS solutions, and I rate Vertica support to be much better.

In my current company I was not responsible for the switch. As far as I know, they switched from PostgreSQL, especially because of performance of analytical queries processing large data.

Just getting Vertica running is straightforward. However, with an increasing number of customers, we had to develop our own tooling. For example:

• Automated deployment
• Monitoring, alerting
• Backup/restore.

Start with license per 1TB. Starting from hundreds of TB there is unlimited licensing to be considered.

Move historical data to HDFS/S3 which are significantly cheaper or even free.

Vertica is delivering more and more features to support load/unload for external storages.

2012 - Detailed evaluation including benchmarks of: Greenplum, Vectorwise.

2017 - Evaluation of features and initial communication with vendors, if needed, for: Greenplum, EXASOL, Amazon Redshift, Spark, SAP HANA, IBM dashDB, Snowflake, Azure SQL.

It is easy to implement this solution for one customer. By tuning the model (projection design) you get incredible performance. You won’t face issues with metadata (catalog) layer up to tens of thousands of tables.

It can be a challenge to operate clusters for many customers with varied data pipelines. Consider using Database Designer.

Don't hesitate to push Vertica (through support/product management) to improve it.

Consider implementing your own tools to automate performance tuning tasks.

Replication

Replication and Node recovery in 8.0.

vbr.py needs to be improve to support diff no of nodes source to target.

5 years

No

Yes

No

8

8/10

The primary use case is machine learning and currently, I am working on IOT projects.

With Vertica, I am able to make changes using other Vertica features and I do not have to start the project over. The Vertica tool is very powerful but you cannot purchase the product based on individual features. 

I am highly trained on Vertica and I am resistant to using other products because I do not have experience with those products. Some of the most valuable features are cybersecurity and backup.

The biggest problem is the cost of cloud deployment.

I have worked with Vertica for the past five years.

The initial setup is straightforward and easy deployment.

I would rate Vertica an eight out of ten.

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 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 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.