Amazon Redshift Reviews

I use Amazon Redshift for the creation of SQL ETL procedures in a business system. Business people check this in a front-end application, and it helps them plan sales for the next year.

Redshift is being deployed on a Microsoft Azure server.

There are about six people working on this project and using the solution, but there are many similar projects running on Oracle and Redshift.

I like it because the usage is very similar to Microsoft SQL server. The structure of the query and the temporary tables are very similar. Until recently, I thought it was the superior database, but now I think that Redshift is better.

The explain panel in the Redshift database could be better.

I have used this solution for 10 months.

The solution is stable. I haven't had any problems or downfall with the database in the 10 months that I have used the solution.

I have also used Microsoft SQL server and Oracle.

Setup was difficult because I had to set up 25 connections with different users and passwords. The connections have been predefined, but there were still problems when trying to connect for the first time. I had some problems with some certifications that were malfunctioning. This might have had something to do with the functionality of my keyboard because if I pushed a random combination on the keyboard, it would delete the certificate from the folder and the connection wouldn't work. I think this is a problem with the remote desktop rather than with Redshift.

I would rate this solution as eight out of ten. I can't give it a higher score because there are some issues with variable character columns in the table. Otherwise, it's a great database.

Some of my former colleagues from a previous job have joined my organization, and they have had some issues with the SQRs because some things work differently in Redshift, like the partition bar. If someone has issues with Redshift, my advice is to check with support.

I use the solution in my company for our data warehouse and databases.

The high price of the product is an area of concern where improvements are required.

I have been using Amazon Redshift for three years.

My company uses IBM Cognos as a reporting portal on top of Amazon Redshift.

My company moved from Netezza to Amazon Redshift since the latter is available on the cloud platform. My company used some migration tools to shift from Netezza to Amazon Redshift, and it took almost a year.

Amazon Redshift was not helpful in improving our organization's functioning, and I believe that previously, we had a better database named Netezza in place.

It is an expensive product.

The tool can handle some large-scale datasets for our company since we use data shares.

I am satisfied with the performance of the product.

The product is able to fulfill my company's needs associated with data analytics.

Amazon Redshift is used as a storage tool.

I rate the tool a seven out of ten.

For the on-premises version of Amazon Redshift, we need to start from scratch. However, with the cloud version whenever you want to deploy, you can scale up, and down, and it has a data warehousing capability. Redshift has many features.

They have enriched and elaborate documentation that is helpful.

We are using third-party tools to integrate Amazon Redshift, they should create their own interface on their own for it to be easily connected on the AWS itself.

I have been using Amazon Redshift for one year.

Amazon Redshift is reliable and has high availability.

The scalability of Amazon Redshift is good.

We have approximately 20 people using this solution in my organization.

Before we were using Amazon Redshift, we were working with Postgres, Greenplum, and Oracle SQL. These were on-premises databases, and we migrated to the cloud.

The price of Amazon Redshift is reasonable because it depends on the usage that you use and for DWH for the long term.

I would advise others that if they have a large set of data where you have a less number of updates, then choose Amazon Redshift. If there is more update and fewer inserts, then do not use Amazon Redshift.

I rate Amazon Redshift an eight out of ten.

We use this solution for production and customer data for one of the lines of the business, which is basically one of the warehouses. I oversee the whole architecture infrastructure.

The price isn't bad for the performance for a cloud data warehouse. It's also connected to Databricks but uses SQL. It's comparable to BigQuery. If the analyst knows SQL, which is comfortable and easy to use to go between all of these tool stacks, I think it's reliable. It's a secure and reliable data warehouse.

The performance is good, and it's pretty fast. We also have Looker and MOLE connected to it for visualization, which works seamlessly. We're storing a lot of data. There's a lot of transactional data, clickstream data, and telemetry about the customer, what they're purchasing, call logs, and marketing data.

The analysts are familiar with SQL, and they're able to do this. Even the data scientists who aren't that savvy in Python, because they are very strong in SQL, are able to interact with it very quickly. I'm able to bring in more analysts for support.

There are physically too many pipelines for a company of this size to maintain. For a data scientist, it's very difficult to learn the data in all of these different environments. It's easier to train people in just one environment to start with, like Snowflake or Databricks. It's difficult to have so many technologies that are very comparable, and each comes with a price tag.

I have used this solution for seven months in my current company, but I have also used it in a couple of my previous companies.

The stability is good. For a mid-size company, it's very stable.

It's very scalable.

I would rate the technical support as 10 out of 10.

We had one or two tickets, and they responded extremely quickly. Technical support is good, but that's because we aren't running into many issues. The solution is pretty stable. The individuals who set it up did a very good job.

It wasn't too complex because only a few people were needed to set up the solution.

It's not very pricey compared to other tools. I would rate the price as 5 out of 10.

In my organization, we also use GCP, Amazon EC2, Databricks, and Snowflake. We also have Delta Lakehouse. I'm going to move everything into the Delta Lakehouse. For a company of this size, it's a lot of tools to physically maintain with a small data engineering team.

I think Snowflake has a few more features. In Redshift, you need to write a bit more SQL in some instances, but it's very user-friendly and fast. It can be used as a data warehouse solution as well. It can also do some analytics.

Redshift is comparable to other solutions. I wanted to go with Amazon EC2 because we also have Databricks, and I think I can cover some of those features with the combination of that.

I would rate this solution as eight out of ten. It's a very strong solution.

My advice is to do your research and see if it makes sense for you. You can always request a demo from Redshift.

It is scalable, easy to use, and has very good query performance. It is serverless as well.

They introduced machine learning directly in to Redshift, and you can now query using machine-learning functions.

It's very easy to migrate from other databases to Redshift. There are migration tools dedicated for this purpose, enabling migration from other databases like MS SQL directly to Redshift. The majority of the scripts will be automatically transposed.

AWS Snowflake has a very good feature for cloning databases. It makes it easy to clone a data warehouse, which is useful. I would like to see this feature in Redshift. 

We have been using Amazon Redshift from 2013.

For stability, I would give a rating of ten out of ten.

We have 16 Redshift users in our company, and I'd rate the scalability at ten out of ten. 

Redshift's technical support has been great.

The initial setup is simple.

In comparison to the price of similar solutions, Redshift's cost is the lowest.

I would recommend Amazon Redshift and would rate it at nine on a scale from one to ten, where one is the worst and ten is the best.

My primary use for Amazon Redshift is for analytical purposes.

In terms of valuable features, I like the columnar storage that Redshift provides. The storage is one of the key features that we're looking for. Also, the data updates and the latency between the data-refreshes are valuable.

Pricing is one of the concerns that I have because if you compare Snowflake with Redshift, it provides some of the same services, but at a much cheaper rate. So pricing is one of the things that it could improve. It should be more competitive.

Otherwise, everything else looks good, especially the data storage and analytical processes.

I just started using Amazon Redshift. I'm still learning about the product and about how the pricing and the dynamic skilling are done.

I understand that Amazon Redshift is quite stable and it has features like higher readability. So I think it should be a good product to be used.

I have not been in touch with support but I will be needing their support in the near future to help me set up the environment.

In terms of the initial setup, as I said I've still not started using it, so I pray that it's going to be pretty easy for me to set it up.

Of course I would advise others to choose Amazon Redshift, as long as pricing is not a concern for them.

On a scale of 1 - 10, where 1 is the worst and 10 is the best, I'd give it an 8.

We mainly use the solution for marketing analytics.

The solution works fast. I use Redshift to clear a lot of web page data. I use it mainly as an extraction tool to obtain the information I need for a project and store it in parquet files on a disk. Later, I work on the data using Python. I write back all my final results to Redshift and store the temporary files on a local machine.

They should provide a structured way to work with interim data than to store it in parquet files locally. Also, Redshift is unwieldy. There should be better integration between Python and Redshift. It could be more accessible without using so many sequels.

They should make writing and reading the data frames into and from Redshift easier. The performance could be better. I have used Redshift for extensive queries. For the large tables, it's easier to unload to Redshift, but subquery tables that run complex grids are slower for configuration. I have to use the unloaded command to unload the whole table. Further, I have to read the table into a server with extensive memory in Python and process the data ahead. It's not optimal. 

We have been using the solution for two years.

I rate the solution’s stability as a nine.

The solution is scalable. It handles different loads very well. We have 80-100 users using the solution in our company.

The setup was quite complicated. For instance, if you use AWS Glue to automate loads into Redshift, setting up the security for the requirements between the two is complex. I've struggled a lot to set up the cluster on VPC and to get all the endpoints set up correctly with the right access and services. Especially from Glue's endpoints, I had to repeat the same process every time. It consumes a lot of time. In comparison, the CloudOps executives do the setup very quickly.

I have heard complaints about the solution’s pricing, and thus I rate it as a five.

I rate the solution as an eight out of ten.

Column store and distributed processing is optimized for read access. We grew to 3000+ users with no impact.

Column store is a data compression technique for relational data. I’m using it now in SQL Server 2016. We configured a 16-core VM for handling requests on the DB. The recommendation was to separate inbound data packets into related chunks, which were 1/16th of the size.

This way, the import process could make full use of parallelization, and it worked. We imported 20 million rows of sales facts in less than 15 seconds, and the content was query-able immediately. I’ve never seen that before. This was impressive. This meant that we could completely rebuild the data warehouse to “current” from "scratch" within minutes, assuming that the data was in S3 already.

Tables that would typically be 2GB in size are now about 250MB. This means more data in memory. You can also configure the tables to live in the memory of all of the available cores. This is good for small dimension tables. You can also fragment them across all cores, for the larger fact tables. This allows for distributed query processing. Once you set it up, it just worked. It was all specified in the PG-SQL table statements.

There were two data centers in Sydney that were guaranteeing us a distributed solution. We really didn’t notice this. It was more of a check box situation. At one point, there was an outage at AWS, but it didn’t impact our operations directly.

This has given us the ability to provide metrics to the large number of company staff on their performance without impacting core systems.

I’d like to see these RedShift features arrive in other languages, such as SQL's ColumnStore index.

.

I have used this solution for three years.

There have been no stability issues.

Technical support always met my expectations.

I was on a team that was using AWS tools for Dick Smith Electronics (now liquidated). The tools ceased use in February of 2016.

Prior to that, we were using them fully for about 3 years. We loaded data to Redshift according to the best practices included in the online docs and through consultation with the AWS staff. The combination of S3 and Redshift for this purpose was very high in performance. Redshift was used to provide the data model to an instance of MicroStrategy for BI reporting.

We were using MicroStrategy, which generated all the SQL that our reporting services needed.

As such, I could only comment on the data engineering phase. Technically, this was so impressive that I don’t know what to add. I don’t recall feeling that it missed anything. If anything, I was not using all the available features. AWS documentation is great in this regard. You can tell they have put a lot of thought into it.

A lot of the future direction in database technology has to do with memory optimization and concurrency (VoltDB). This is more targeted towards transactional processing, and not data warehousing.

Memory-only data warehousing solves a lot of access issues without having to think too hard about the problem from the consumers' point of view. I am sure that you can already configure this.