Amazon Redshift Reviews

The solution is used to handle unstructured data.

We have been using the product for some time. We are exploring and learning from the new offering of the product.

AWS provides an ecosystem of different offerings. The product offers good support for the data lake. It also provides a lambda function for automating flows.

The initial deployment was complex.

I have been using the solution for a year and a half.

We have an SLA of 99.99%. The product is available most of the time. The vendor maintains the SLA well. They also have a scheduled maintenance window.

The tool’s scalability is pretty good. I rate the scalability an eight out of ten.

The initial support for moving to a serverless database was very good. AWS provides good support. The technical support is not consistent, though.

We need a solution architect from AWS to help us with deployment.

Initially, we saw a return on investment. Now, the cost is going up according to our use cases. We need to optimize the cost.

The cost must be improved. We’re concerned about the cost. It’s driving a lot of TCO for us. We are looking for alternatives to optimize the cost.

Nutanix also provides similar products. It also offers different options for cloud providers.

It’s a pretty good solution. We plan small and grow big over time. Overall, I rate the product an eight out of ten.

We use it for data warehousing. Currently, I'm setting up a data link with Redshift to fetch data from our data lake.

The most valuable feature of Redshift is its cluster.

Redshift's serverless technology needs to improve because not everyone is technically inclined. Organizations want to quickly access and import data into their data warehouse without hassle.

Redshift's ETL tool, Glue, is not seamlessly integrated with Redshift. I've encountered many instances where it couldn't fetch the perfect data type from the source, which should be intuitive. Snowflake's ETL tool, on the other hand, is more intuitive and seamless.

I have been using this solution for two years. I am working with the latest version.

I haven't faced any stability issues because when it works, it runs continuously.

The initial setup is a complex process, especially for someone who is not familiar with nodes and configuring terms like RPUs. You need to consult the documentation to understand what an RPU is.

Moreover, Redshift can be difficult to maintain, especially the Redshift cluster instance.

When it comes to the initial deployment and implementation process of Redshift, there are two types of nodes to choose from: DC2 and RA3, which are for different requirements based on the load. One is for storage, one is for storage and checking, and one is for the computing center.

First, the user needs to know their exact requirement, unlike Snowflake, which automatically scales up and down based on the requirement using the Retrieval Service tool.

The service has not matured yet, and for the Redshift cluster, scaling has to be done manually. The cluster also needs to be set up manually, which is not ideal, especially when Snowflake is already in the market.

It is easy to deploy if you already know how to use Redshift. But if I were a new customer, I might need assistance.

Redshift is a bit less costly than Snowflake, but the effort justifies the cost for Snowflake.

I would suggest starting with a three-cluster that is DC two large, especially if you are setting up a cluster-based search. We offer a three-month or one-month trial, which will allow you to see if you can handle the manual scaling up, scaling down, and maintenance of Redshift. If not, then you can switch to a serverless data solution.

Overall, I would rate it a seven out of ten.

It is storing warehouse data for the organization. We commission data warehousing, storage of data, and reporting.

Data Science and Machine Learning are valuable features. We have found Machine Learning use cases are very nice.

Infinite storage is available in Snowflake and is not available in Redshift. Analytical tools for integration would be helpful in the future.

I have been working with Amazon Redshift for seven years now.

We have found Amazon Redshift to be stable.

We have no problems with scalability.

The initial setup is very smooth and took us about six months to deploy.  The cost is comparable to Snowflake.

I would rate Amazon Redshift a nine out of ten. I am very satisfied with it.

We stored all of the data in the S3 bucket and would like to have it stored in a data warehouse, which is why we chose this database. 

It would be very easy for us as an end-user, who would like to access the data, rather than draw it post-transformation and store it at a database level.

The TP transactions for the creation of the tables does very well.

It is quite simple to use and there are no issues with creating the tables.

The managing updates, deletes, and role-level change performance is very low. For example, while you are doing inserts, updates, deletes, and amalgamates, the performance is very, very poor.

If you want to query the database after you have a lot of terabytes of data, the load, performance-wise, is very low.

Looking at the performance of the query, querying the database, and especially with the amalgamates when it is getting updated, it is really poor.

We like this solution and have tried all of the native services; they were working quite well. The only concern about Redshift was managing the cluster, especially the EMR cluster. Our company policy was not to use EMR clusters, especially with the nodes failing. There were many instances of downtime happening. Essentially, there was too much data traffic.

The other drawback was the CDC, as we do not have any tools that can support it.

Creating the structure is easy on the DDL side, but after you create the table and you want to transform the data to store it in a database, the performance is poor.

It takes a lot of time to ingest and update the data. After you ingest the data and someone wants to fetch it in the table, it takes a lot of time performance-wise to return the results.

We have been using this solution for three months.

We are using the latest version.

There are issues with stability and it should be compared with Snowflake.

This solution is scalable. We scale up and scale down manually when we are required to, we do not have an automatic setup.

We have three or four people using this solution.

We have contacted technical support to give our opinion and recommendations or feedback and they agreed that it needs improvement.

Previously, we tried the Snowflake database, which works really well. The expectations were really good with the performance, also the DDL, DML operations on the processing of the data.

The initial setup is simple and we did not find it very complex at all.

The time it takes to deploy depends on how many tables you want to create, or how many tables will you merge the data with.

We are switching to Azure, although not because of the product or the services that we did not like. It's about AWS being competitors for logistic companies that we are working with. Also for security reasons, we do not know how secure the data is on the cloud.

If you are competitors then you don't know if the data can be accessed by your competitor, and the team can be looking at a demographic, which could impact your sales.

We have only just started using Redshift, but we are not really satisfied with it.

I would rate this solution a six out of ten.

Columnar storage technology is the most valuable feature of this solution.

We can get the SLS/SLAs in our daily processes.

Some improvements can be brought about in:

Restore table:

I would like to use this option to move data across different clusters. Right now, you can only restore a table from the same cluster.

Right now, the feature only permits bringing the table back in the same cluster, based on the snapshot taken. I would like to have a similar option to move data across different clusters, right now I have to UNLOAD from cluster A and then COPY in cluster B. I would like to use the snapshots taken to bring the data in the cluster I need.
Maybe current design cannot be used, because it is based on nodes and data distribution.

But, our real scenario is: if we lose the data and we need to recover it in other cluster, we have to do:

1) Restore table in current table with a different name

2) Unload data to s3

3) Copy data to a new cluster. When we are talking about billions of records is complex to do.

Vacuum process: The vacuum needs to be segmented. For example, after 24 hours of execution, I had to cancel the process and 0% was sorted (big table).

Vacuum process:

The vacuum needs to be segmented, example after 24 hr of execution, I had to cancel the process and 0 % was sorted (big table)"

For big tables (billions of records). if the table is 100% unsorted, the vacuum can take more than 24hrs. If we don't have this timeframe, we have to work around taking out the data to additional tables and run vacuum by batches in the main table.

Why, because If I run the vacuum directly over the main table, and I stop it after 5 hrs, 0 records will be sorted. I would like to run the vacuum over the main table, stop when I need but get vacuumed some records. Like incremental process.

I have used this solution for around three years.

We did encounter stability issues, i.e., if you are using more than 25 nodes (ds2.xlarge), the cluster is totally unstable.

I have not experienced any scalability issues.

I would rate the technical support a 9/10 for normal issues.

However, for advanced issues, I would give it a 5/10 since I had to go directly with the AWS engineers support.

Initially, we were using the Microsoft SQL solution. We decided to move over to this product due to the DWH volume and performance.

In my opinion, the setup was normal.

Based on quality of the product and its price, it is the one of the best options available in the market now.

We also looked at the Oracle solution.

You need to make sure that the space used in DWH has to be a maximum of 50% of the total space.

You must create processes to vacuum and analyze tables frequently. Also, before creating the tables, you should choose the right encoding, DISTKEY and sort keys.

We use Amazon Redshift for our data warehouse to store a lot of our data for a client.

The most valuable feature of Amazon Redshift is its ability to handle really large sets of data. In our case, the solution does a lot of things that would be difficult to do otherwise.

Amazon Redshift is a little more expensive than other products.

I have been using Amazon Redshift for four years.

Amazon Redshift is super stable, and we haven't faced any outages or other issues.

The solution's scalability has been fine regarding how much data we can load into it. Once the solution is set up, we pay for what we use. Three people are using the solution in our organization.

Users should select Amazon Redshift depending on what their needs are. Amazon has other cheaper database products, but Amazon Redshift is a really good option for users who need a lot of computation.

Overall, I rate Amazon Redshift ten out of ten.

I have used DBeaver to connect to SAP Amazon Redshift and my main use case is for SQL. I map data from a graph database into SQL.

Amazon Redshift has benefited the company by allowing us to scale. 

The solution could improve in handling more data formats and more native support for RDF.

I have been using Amazon Redshift for approximately one and a half years.

The stability of Amazon Redshift is good.

Amazon Redshift is a scalability solution.

I have not used technical support. If I need support I ask my colleagues.

The initial implementation of Amazon Redshift is simple. There was not anything difficult about getting started with the solution.

It's important to have a grasp of the environment you're working in, including a basic understanding of Amazon AWS. Additionally, when selecting an interface to work with, it's essential to choose wisely, as you'll likely be using it for an extended period of time.

I rate Amazon Redshift an eight out of ten.

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.