Amazon Redshift Reviews

I used it as part of the Amazon Connect integration; I had to implement Redshift for a couple of customers. It's used for various use cases involving reporting and exporting data to external sources. I have also used it for some analytics integrations.

The use cases I have typically worked on involve transferring Amazon Connect data to different systems for analytics. The two or three deployments I have done with Redshift are more or less similar because it acts as a kind of data middleware. 

Redshift effectively gathers data from various sources and facilitates the integration of that data into different destinations. This is typically used for insights collection, data showcasing, and integration into a standard ETL process.

So, the overall performance and speed of Redshift have affected the query times.

For the use cases I worked on, particularly on the Connect side, the query times with Redshift are pretty straightforward. We started using Redshift for these cases, and it significantly helped. To achieve faster results from Redshift, we first need to optimize the queries. It does reduce a lot of time in how data is gathered and then presented from the queries.

For me, the most valuable feature of Redshift is the way it operates as a reliable Amazon service. It has the capability to gather data from various Amazon sources and can be easily integrated with some maintenance configuration and code; Lambda functions are required for this. It can be used in multiple places. 

It all depends on the use cases, how we can actually ship the data, and how we can use the data from multiple sources. It is a typical reliable software and works very efficiently with Amazon.

For Amazon Connect combined with Redshift, the integration is mostly straightforward. Using Redshift always depends on the use cases, as there are other methods Amazon Connect can use to achieve its goals. As for Redshift itself, it can be used to build pipelines.

When working with third-party services requires additional integrations and configurations, which can sometimes add more cost.

From the Amazon Connect side of things, we have integrated Redshift. However, as an overall product, I have limited experience. 

But from what I have experienced, whenever we do a Redshift integration, it needs to be planned carefully because although Amazon supports multiple data sources and different data consumption, Redshift needs to be configured very effectively and requires dedicated shared knowledge for successful deployments. 

Redshift is a major service of Amazon and is very scalable. It enables faster recalculations and data management, helping to retrieve data quickly. It’s a relatively old service within Amazon's offerings, with at least 10,000 customers. I've seen cases in different organizations where users experienced up to 35X times increase in throughput while using Amazon Redshift.

It's pretty much straightforward. I just need some sort of configuration and a bit of integration, and then that's it. We should be able to get that done.

For first-time usage of Redshift, the process is pretty straightforward, thanks to the documentation provided by AWS and the straightforward integration with Amazon Connect. 

It didn't take me much time to create, deploy, and configure. It’s very straightforward. However, having some prior knowledge about Redshift can speed up the process significantly. 

For me, coming from a different background and learning about Redshift for the first time, I ended up reading some database documentation and doing some trials and testing before committing the production data.

For someone who knows a bit about how databases and data warehousing work, it's quite straightforward to learn Redshift. It's easier for those involved in analysis, reporting, and ETL data warehousing, specifically database developers or data warehousing developers; they can learn it faster. 

However, for someone without this background, it might take a bit more time to understand the concepts and how they integrate in different ways.

Overall, I would rate it an eight out of ten because it has been straightforward for my use cases. It's easy to integrate for those use cases.

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.

There are many use cases, as I've worked with Amazon Redshift at different companies. Initially, we used it as part of the AWS suite, which made it easy to get started. We were able to move data from MySQL and PostgreSQL into Amazon Redshift, and we even used it in a production environment. However, the scalability of Amazon Redshift was not enough for our needs, so we switched to Snowflake.

The most valuable feature is its seamless integration within the AWS ecosystem. If your data is already in S3, it becomes easier to port it into Redshift and work with it. 

Redshift allows you to transform different data formats and consolidate them into one Redshift cluster. This means you can transform various siloed data sources like Excel files and CSV files into Redshift. 

With Redshift, you get a suite of applications that enable you to drop a file and consume it into the data warehouse, facilitating the use of Power BI dashboards, Tableau dashboards, or custom dashboards on top of Redshift data. This setup process is much smoother compared to other tools that may require going through legal MSA (Master Services Agreement) and other complex procedures.

As our scalability requirements and data growth exceeded expectations, Redshift didn't scale up to meet our business needs. So, at that point, we made a switch to Snowflake, which provided the scalability we needed. So, scalability is one area of improvement.

One area where Amazon Redshift could improve is in adopting the compute-separate, data-separate architecture, which Delta, Snowflake are adopting, and a few others in the cloud data warehouse spectrum. Although Redshift introduces Aqua to achieve some level of scalability, I still feel that when it comes to scaling up, whether it's vertical scaling or horizontal scaling, there is a noticeable amount of downtime for end consumers. So, if I need to switch from DC1 to DC2, or from one compute/storage optimization to another, I have to bring down the entire cluster and then bring it back up. That's a pain point.

I have been using Amazon Redshift since 2012.

In terms of stability, I would say Redshift's workload management is generally stable. However, the way Redshift distributes the workload is not as scalable. I often don't have clear visibility into what queries are on hold, their priorities, or other relevant information. 

On the other hand, Snowflake provides more transparent insights into the queue and running queries, and it also informs me when the queue will be drained. Snowflake's multi-cluster approach to handling workloads surpasses Redshift in these aspects.

I would rate scalability a seven out of ten. There is a need for improvement in terms of scalability. 

I did contact customer support regarding a data breach. In terms of handling such incidents, I found their customer support to be excellent. They were proactive in ensuring that our account and data were not compromised. They guided us through the necessary steps to recover and resume operations. 

Positive

The initial setup is seamless. You just need an AWS account for the setup. I would rate my experience with the initial setup a nine out of ten, where one being difficult and ten being difficult to setup. 

If I have to scale maintenance, maintenance is much easier in Amazon Redshift, provided you have data governance in place and constantly monitor the usage and things of that nature. The roles and the RBAC are not so convenient because everything goes to IAM. Whereas Snowflake has flexibility in setting up RBAC, which is entirely different than what Amazon Redshift has to offer.

If it fits the bill and the business purpose, I would recommend using the solution. But when it comes to business needs, that's when all these things matter. Whether one tool versus the other supports all the business needs and meets the SLA and RT, or whatnot, then we are talking about different products. So it's based on business needs. 

Overall, I would rate Amazon Redshift a six out of ten. They still need to adapt the maturity and be on par with the open source community and ecosystem. Recent technology adoption is towards Delta. Microsoft is moving towards Delta. A lot of ecosystems are moving towards Delta, but Amazon Redshift is not making its move towards this technology, which is serving the engine. So that aspect has to grow.  So, there are a lot of aspects where they can improve.

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.

We use the solution for data storage of reports.

Redshift Spectrum is the most valuable feature.

The product must become a bit more serverless. Users should have to pay only for the resources they consume.

I have been using the solution for one year.

The tool is quite stable.

Around 20 people in our organization use the product. The tool’s scalability is good.

The solution is deployed on the cloud. The initial setup was pretty easy.

The product is quite expensive.

We also tried using Athena. However, Redshift was faster.

We use the tool because we have everything on AWS. Amazon Redshift is best for fast reporting. People who want to use the solution must try using Athena. If it is not fast enough, they can try Redshift. Overall, I rate the product an eight out of ten.

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.

Redshift is an AWS warehouse solution. We have structured datasets, and we don't load all the amplitude data into Redshift. We first do this via Hudl, a data integration solution partner, but then later, it's directly loaded by an interaction. Then we run DBT against Redshift. We have our data models in DBT, and we run data analytics threats against the data warehouse.

Service accounts are used in both Amazon Redshift and Google Cloud. For example, I could create a service account for my desktop to access Redshift or a service account for multiple users to access Redshift. In BigQuery, creating a service account is very simple, and you get full control over the access, so you can limit what the service account can do. This prevents accidental exposure of data or deletion of data. Only certain features are available, which is very handy.

Postgres syntax requires 25 synthetic scrubs to Postgresify. It's handy, but there are no blockers when using the query. It's more competitive, but the price is very reasonable. I was always aware of what I would pay, and if I reserved servers, I knew what it would cost. There is no alternative in choosing a solution. We had to use the server version of AWS, but it had limited features. A few features were lacking, which couldn't front Redshift against it or access it from the API. We had our nodes, which were sent from Amazon. It has a minimal setup, with two services running only. 

It was predictable because the performance was good. When a complex BBT model was running, we reached its limits. If there was a one-node setup, not all the storage was available on the server. For example, in a machine with 72 gigabytes of storage, only four were available in a single setup. I had another node, with 64Gb. All the storage of the two servers was available and when you are running these complex queries, it's not only a bit of computing but also temporarily eats up the storage. I couldn't use a single server because temporary tables ate up the storage. BigQuery’s authentication is straightforward. Besides that, it's doing what it's expected to do. There are no major problems.

It would be good to see Redshift as a serverless offering. The proposition may be unclear, but at the time, there were certain limitations with the pay-as-you-go offering. However, a serverless offering would be more flexible on-demand pricing, which would be good to see because Redshift is not expensive, but I always have to buy a new server if I need more computing than I have. Setting up a new server is an easy task, but it would be better if I could scale my Redshift cluster up or down as needed; still, there is a need for manual control. For example, my analyst team is working on a job that requires a lot of computing and is only needed for this month, week, or even today. The job should scale up and down automatically, but it is not yet fully developed.

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

We've had some cases where queries would get stuck, and we'd be on them for ages. I don't have the transparency to see what other queries are already running or if we're running out of some kind of resource. There weren't many major problems, but sometimes we'd get these annoying issues, especially when running complex queries.

If we can immediately set up new servers, it's easy to do, but an automatic solution or a threshold would be ideal. This feature may be already available, but I'm not sure. We have three users using this solution. I rate the solution’s scalability a seven out of ten.

Amazon Redshift support is not always available, so it can be challenging to reach them. You have to buy time and schedule with them. There is no real need for a technical hub, but it is not there when there is a need.

The initial setup wasn't very complex.

The solution has very competitive pricing. It can be expensive for the first time when you are building your site. Time and the amount of data also take some time to downsize. It would be cheaper than to have a server, but for Plexigos storage, you have to buy a specific size of compute power. Initially, it was more expensive than BigQuery pay-as-you-go, but it got cheaper later. The more data you have, the relative ratio becomes cheaper. It depends on the use case. In AWS, you must invest and understand the setups, such as what kind of servers you need. Then, you can set up your own, which can be very cheap. Redshift can be engineering-focused to set up, which is not ideal. Azure and Google Cloud, are more efficient for data analysts who are not data engineers. But it can be effective once you get used to it and set up a process. If you are utilizing the on-demand stuff, Redshift is the only vendor offering a dedicated service.

From time to time, the solution needs to be restarted for maintenance. I recommend BigQuery over Amazon Redshift. I don't have experience with Snowflake, but it's set to be more feature-rich than BigQuery or HSA. I was more happy using BigQuery. Redshift is doing what it's expected to do, but you had to invest in learning the setup. Overall, I rate the solution a seven out of ten.

I have used it for our reporting solution requirement. We gathered data from different processes and applications, like the high system process. Clients can review the data; we use it for connections and reports. Additionally, Redshift generates some configuration files without using an application.

For reporting purposes, Redshift is a great tool to use. Redshift has an advantage when it comes to administration, making it easier to manage and collaborate. Additionally, its server architecture allows for faster processing. Redshift also supports prepaid costs, which is another great feature. However, similar features are also available in Azure.

Redshift has some advantages in terms of administration and performance.

When compared to Snowflake, Amazon Redshift does not have the capability to dynamically increase the VM file. However, Amazon Redshift provides a virtual database called 'VW' that allows you to increase the size of the warehouse to run faster on a monthly basis without changing anything. This feature is not available in Redshift. So it's a limitation of Redshift.

It's not possible to immediately increase the virtual warehouse size in Amazon Redshift. When compared to Snowflake, we cannot increase the virtual warehouse size in Redshift. 

I have been using this solution since 2015. 

I don't see any issues with data loss or any other problems. Although there might be some loss in the data center, we monitor it, and everything is enabled. In such scenarios, the turn-up time is much faster. We've been using it since 2018, and I've got the same product for another customer using a limited rate. So, I don't see any significant impact, and it's a very stable product.

We have to consider the scalability of this solution carefully. In production, we have a proper size. We allocate 40% for data storage and 60% for temporary segments. We cannot increase data storage usage beyond 50%. It cannot exceed 80% of the total utilization, including network speed and query performance. We monitor all of these carefully.

So if the CPU utilization goes beyond 80%, I recommend upgrading to multiple nodes. It ensures that there won't be any issues. Around 30 people are using AWS and Azure modules along with me.

We have contacted the Redshift team for support related to other installations, such as WDL configuration for project implementation for a web application. When it was not working as expected, we had to provide authentication for the web chat. So, we used to contact them for that kind of knowledge.

The initial setup depends on who is doing it. In my opinion, it doesn't require much knowledge. Since we've been using it for a long time, it's much faster for me, but it might not be the same for others.

It's on the expensive side.

One reason we chose this solution is that we are in the process of moving everything to the cloud. But that's not the only reason. My company wanted to consolidate everything into one system, and AWS provided all the necessary information in one place. For example, Lambda is for specific storage and limited membership; all this information is available in one cloud network. This way, data segregation is much faster and easier to use. It's just everything in one cloud network, so we decided to use it.

I would recommend it. However, I think we need to consider other configuration levels. You need to decide, and I would not go with the first option.

To evaluate the data you are planning to migrate, we need to assess the environment. What is the value of your data, and what type of data is it? The density of the data is also important. Before implementing Redshift, we need to ensure that the AWS configuration is activated. After that, you need to set up enrollment and increase your storage. I don't recommend making a purchase on the same day, but it is a critical moment at a high level.

I suggest purchasing a renewal that meets the deposit requirements so that you can have a good experience and optimal performance. You can increase the budget for the building process. If you have the right team, such as those with experience in AWS or those who are learning about Azure databases, they can start using Redshift without any issues.

Overall, I would rate the solution a nine 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.

We were using the solution for our data backup, but we wanted to optimize it, so we turned to AWS Glue. Amazon Redshift wasn't really great for us and wasn't working out.

Amazon Redshift was used for data storage while moving back from S3 to Amazon. However, it lagged, taking its own sweet time for data backups which also depended on the server location. Because of the aforementioned reasons, we started losing a lot of data that wasn't even real-time data. Ultimately, this affected our analytics at the end of the day. Also, we have been trying to do some work on our AI models, which emit out recommendations based on the live dataset. There were a lot of lagging issues. So, for example, sending out somewhere around 0.1 million or 100,000 emails used to take almost 12-14 working days, and this also includes the process of pulling all the data and sending them to CronJobs. Since we wanted all this work to happen in real-time, we had to get rid of the tool.

I would like Amazon Redshift to improve its performance, analytics, scalability, and stability. Other than these points, I am not aware of any other areas to address since Amazon provides a variety of independent services for their customers to choose from, and if one were to express dissatisfaction with Amazon Redshift, Amazon would likely suggest AWS Glue as an alternative. Similarly, if another issue arose, Amazon might recommend Amazon RDS. There are a lot of things they try to upsell to you, each with its own pros and cons and in different packages offering different perks. So, it all depends on your business needs and what you choose for your business. I wouldn't criticize Amazon for this because they have created packages tailored to their customer's needs, which helps to prevent customers from looking elsewhere.

I have been working with Amazon Redshift as an implementer for three years.

Stability-wise, it has a lot of issues with threats, and that is why we went for a threat shift optimization. In short, I mean to say that it is not stable at all.

If you require a highly scalable solution, I would not recommend Amazon Redshift. We currently have 12 clients using Amazon Redshift, and the scalability of the solution is terrible. In terms of scalability, I would rate this solution a three or four out of ten.

Amazon Redshift has a lot of documentation, but the setup is fine. Three years ago, the solution's deployment process took over a month or a month and a half.

Every solution has a cost and comes in different packages. Considering these factors, AWS Glue is on top. Though Amazon Redshift is good, it depends on what kind of business you're trying to do, what type of analytics you need, and how much data you have.

For Amazon Redshift, we pay around INR 60,000 annually. The cost factor also depends on the number of existing customers. In addition to the standard licensing fee paid for AWS, we incur a cloud storage cost of around a quarter million for the amount of data. We also have to bear additional costs for data security and cybersecurity, which are well taken care of by Amazon, hence the premium pricing. There are several other features and services provided by Amazon that justify the premium pricing.

Amazon Redshift is a horrible solution. I recommend my customer to use AWS Glue since while dealing globally with real-time data, which you need to make decisions, factors like how much cost and data is needed to make a decision should be considered. Apart from this, if customers are paying a huge price for the solution, then probably Amazon shouldn't mind spending on the tool. However, it may not be necessary for small businesses with only a few thousand data points. Although Azure is a better option, some clients prefer AWS, and we had to develop a solution using AWS for our client. Overall, I rate this solution a three or four out of ten.