Snowflake Reviews

I am using Snowflake for migrating data and table backups.

The most valuable feature of Snowflake is its performance. We can access the data quickly. Additionally, it handles structured and non-structured data.

The solution could improve by allowing non-structured data, such as PDFs, images, or videos. We cannot see the data.

I have been using Snowflake for approximately three years.

The stability of Snowflake is good.

Snowflake is a scalable solution.

We have approximately 200 to 300 people using the solution.

The initial setup of Snowflake is easy.

If the use case fits the solution then I would recommend it. For example, if you have large data and want the rational database backed up, this solution would be a good choice.

I rate Snowflake an eight out of ten.

I am using Snowflake for all our apps and data warehousing requirements.

The most valuable feature of Snowflake is it's an all-in-one data warehousing solution. 

Snowflake could improve migration. It should be made easier. It would be beneficial if it could offer some OLTP features. One of our customers was using Oracle for both data warehousing and OLTP workloads, and they were able to migrate their data warehousing workloads to Snowflake without major issues. However, for some of their OLTP requirements, such as needing a response time of fewer than 10 milliseconds for certain queries, Snowflake is currently unable to provide that.

It would be beneficial to see more integration and reporting tools embedded within the platform, similar to what Microsoft offers with its data warehouse and database solutions. Oracle, on the other hand, does not have such features. While Snowflake has a lot of options available on its marketplace, it would be helpful if it could provide more optimal options for users who are migrating from other environments. It would be great if they could follow the same path as Microsoft in this regard.

I have been using Snowflake for approximately one year.

Snowflake is stable.

We have two clients using this solution.

The solution is highly scalable.

We don't have direct support for Snowflake as we support our clients. If any support is required, our clients connect with Snowflake's support team and get the necessary assistance. They own the support account.

The initial setup of Snowflake is easy. We only need to create a login, there is no conventional setup.

When it comes to migrating from a previous platform to Snowflake, it largely depends on the size of the data warehouse, the number of integrations, the existing data pipelines, and the type of data sources. The complexity and size of the current deployment will determine how difficult the migration process will be.

The ROI appears good on paper, particularly in terms of cost reduction in operations. However, as companies have only been using Snowflake for a year and it's hard to say for sure. It looks promising for now, but it will take a year or so to see if it holds up in practice.

Snowflake is a cloud-based solution that uses a pay-as-you-go model. The storage and processing are separated, and you are mainly charged for the processing power you use. Additionally, there is a charge for storage, but the primary cost comes from the processing. You can choose different sizes of processing units, also known as warehouses, for your specific workload or requirements. You pay for the per-second utilization of those computing resources.

Snowflake is cost-effective. However, the cost can depend on how it's being used and how efficiently the code is written. If engineers don't write efficient code and usage is billed based on processing, it can become costly. If they write optimal code and choose the best solution, it can reduce costs in comparison to other options, such as Oracle.

I would recommend this solution to others.

I rate Snowflake an eight out of ten.

The most valuable feature is the clone copy.

In a future release we would like to have a link which would allow us to connect to an external database and create certain views in your own database. This is because it is becoming hard for us to compare the data between multiple sources.

I have used this solution for two years.

This is a stable solution. 

This is a scalable solution. 

The technical support of Snowflake is good. 

Positive

We have seen ROI when using Snowflake based on the insights we get.

I would recommend the SaaS version for their organization. It is not complicated to use. Establishing a private link with current cloud services has been challenging so I would recommend having some kind of a block.

I would rate this solution a nine out of ten. 

Snowflake is a real-time and cloud-based complete ETL tool. You can receive the beta from various sources from Amazon. You can run your reports and do analysis in  Snowflake. Informatica and Tableau should have done this. Snowflake is a modern version of Informatica which is 100 percent in the cloud.

Snowflake has a variety of other ETL provisions that they provide. You can use your own ETL pipeline. Additionally, they provide adapters, and they are always evolving, it is a well-developed solution.

Snowflake has to build more capabilities because they have only built very few adapters, but they're growing and they're building. They should provide provisions to collect ETL pipeline capabilities, reduce developer work, and make more rapid application development, rather than some customizations. There are very few options, but they are building. I hope they will build ETL rapid application development provisions with more variety.

I have been using Snowflake for approximately eight months.

Snowflake is highly stable.

Snowflake is a cloud solution that provides great scalability. However, I am not sure if it is cost-effective.

We have approximately 30 engineers using this solution. We have plans to scale our usage in the future. This is going to be a futuristic solution.

We have not had any problems with the technical support.

The initial setup of Snowflake is straightforward. To set up the ETL pipeline, pull the data, and then generate the reports takes approximately two hours, end to end.

I did the implementation in-house. We have a three-member team that does the maintenance of Snowflake. However, the amount of people needed depends on the size of the pipeline.

Snowflake licensing is more flexible and it is cheaper than other solutions. I can use it for only 10 days for MVP, or three years, and for flexible models. I can scale up, or down, and the pricing is based on the volume and duration. There are many licensing permutation combinations available.

I rate Snowflake a nine out of ten.

Snowflake is used for data warehousing.

The most valuable features of Snowflake are its performance and power.

Snowflake could improve if they had an Operational Data Store(ODS) space.

I have been using Snowflake for approximately four years.

The stability of Snowflake is good.

The scalability of Snowflake is very good.

I have approximately six customers using this solution but in addition, I am directing more.

The technical support from Snowflake was poor previously, they have improved significantly.

Snowflake has an easy setup and it is quick.

There is a license needed to use this solution. There are a few licensing options available. They have a pay-as-you-go option, but it is recommended to pay upfront.

I would recommend this solution to others.

I rate Snowflake a nine out of ten.

I use this solution to create a proof of concept. I also create training for companies on Snowflake.

It is a very easy-to-use solution. It is user-friendly, and its setup time is very less.

They have a new console, but I couldn't figure out anything in the new console. So, if I shift to the old console, I can figure out where to create the database schema and other things, but I have no idea where to go in the new console. That's one thing they can improve. I don't know why they created a new console to confuse. The old, classic console is much better.

I started using Snowflake three months ago. 

It is stable.

It is scalable.

It is so easy that I didn't have to look for technical support. Its documentation is amazingly simple.

I also use Databricks for proof of concept and training. I have used Databricks much longer than Snowflake. Both have their own pros and cons.

In terms of ease of use, UI, and setup time, Snowflake is good. I would rate Snowflake a nine out of 10 from these aspects. In terms of workload, Databricks has higher points. The underlying infrastructure is faster for Databricks, which is not the case with Snowflake. Snowflake is a cloud database. So, in terms of processing power, Databricks has an advantage over Snowflake. Databricks is more suitable for larger workloads, whereas, for a regular or typical data warehouse that you want to run on the cloud, Snowflake is more suitable. 

Its setup was easy. You can create a connection and be up and running within half an hour.

I set it up myself.

I have not been billed yet, but it should be less. I'm still running the trial version, but it seems to be less than Databricks.

You must try it out. It is a wonderful product. I would also recommend trying out other products, such as Yellowbrick, and doing a comparison. Redshift has also come up with some serverless options. BigQuery is also there. BigQuery is as easy as Snowflake. So, my recommendation or advice is to try out these things and then pick the one that suits you. I don't have any bias towards any of the products. I have an impartial opinion about all the cloud data warehousing products.

I would rate it a nine out of 10.

We are also using Apigee we have various consumption patterns, data enrichment, and few shedding of the data, and everything goes into Snowflake. If it is multiple consumers, it goes into AMQ, Kafka, or multiple streams to consume. There are specific APIs that we offer after we send the data into the S3 bucket. We have Apigee APIs for consumption, and there are three to four different patterns. For example, we enrich the data, flatten it, and structure everything before the customers going to go into Snowflake. 

There are going to be specific clients who need specific data from the overall data lake, those are going to be exposed as APIs. We have multiple customers needing the same data and for this, we move them into the streaming Kafka.

Apigee does not communicate directly with Snowflake. We have data registration, and everything is coming into something that is called the trusted bucket. The  Apigee interface API is written off the S3 bucket. The S3 bucket data is moved into the Delta Lake, and where the data are stored from the Delta Lake, it sends it to Snowflake. We have Apigee going to Delta Lake and S3 bucket, but  Apigee does not go to Snowflake, these are two areas where it goes to. 

We have Kafka consuming directly off Delta Lake, and it sends data to Kafka through the AMQ. We have its setup, and we have interfaces that come directly to Snowflake to pull the data. It is then flattened and enriched, and it is used for many purposes, such as reporting.

Snowflake's most valuable features are data enrichment and flattening.

I have used Snowflake within the last 12 months.

The complexity of the initial setup of Snowflake depends on the use case. However, Snowflake itself, we don't set it up. The difficulty comes from the ingestion patterns, depending on what data I'm putting in, what kind of enrichment, and what additional value we have to add. However, it does tend to get complex because we have a lot of semi-structured data which we need to handle in Snowflake. There have been some challenges.

Snowflake has multiple implementations. For example, it can be implemented on Amazon AWS and on-premise. The data between these two cannot work together because they have different time zones. That's where the integration can be difficult because it is similar to them being on separate islands, they are completely separate. At some point, everything is going to go into the Amazon AWS Snowflake, but right now there are two islands that are completely different. We have to pull the data out and send it out again separately through a different pipeline.

In the future, this type of implementation should be easier. The integration could be better. 

I rate Snowflake an eight out of ten.

I have been working on Redshift, Snowflake, and AWS RDS Oracle. In the particular case of RDS Oracle, they were migrating from on-prem Solaris equipment to cloud-based RDS.

I would suggest Snowflake for anyone with the need for a reporting/business analytics view of their data that wants only wishes to maintain technical FTE's around processing the data into or out of a data repository but, doesn't want to go to extent of technical management of "AWS clusters" for the data repository.

It was relatively easy to use, and it was easy for people to convert to it. Moved 168 tables and appropriate indices to Snowflake with minimum modification to Current Oracle DDL. The largest degree of change was setting up the corresponding access Hierarchy to duplicate what was in Oracle ( customer had separate permission structures for application vs Admin/support vs direct reporting access to the data).

The aspect of it that was more complicated was stored procedures. It does not support SQL language-based stored procedures. You have to write in JavaScript. If they supported SQL language and stored procedures, it would make migration from on-prem much simpler. In most cases, if an on-prem solution has stored procedures, they're usually written in SQL. They're not written as what most on-prem DBMS would refer to as an external stored procedure, which is what these feel like to most people because they're written in a language outside of SQL.

The other thing that people found difficult to deal with was that they had several Oracle DBAs who were very experienced DBAs, but they were used to on-prem. They were used to having the ability to turn any dial and flip any switch. Moving to Snowflake did cause some issues there because they had to completely readdress the fact that they couldn't touch the engine, and they had to spend more time analyzing performance.

I probably used it about six months ago. I haven't been working with a client who is currently on this platform.

I haven't had to call on them for a problem at that level.

It was a cakewalk. The biggest thing that's hard to do with it is that you have to do an analysis of performance over time to determine the scale because they separate compute and storage.

Scaling the query to a proper size compute is the larger aspect of the problem for most people. That's because you're looking at something completely different. The problem is that you're now trying to figure out what is the largest compute you need to keep performance where you want it without going too large. If you were in an on-prem scenario, you would tweak and twaddle all the dials. You might rewrite the query, but at the end of the day, you're still working inside the same physical acquisition or same physical resources, whereas in Snowflake, you're literally saying that you've got a 10 million row table as part of your query, but what is the necessary compute facility that you need to run queries that are running against that table.

It is hard to say because we're usually engaged in the transition as opposed to the long term. Their storage costs are easily within pennies of what AWS S3 would normally cost. 

Most of the clients I've been working with are in the financial sector, and they're relatively small. I would put them in an SMB connection. The first thing we have to bring up for people is that they're going to build this. They shouldn't store their data in S3. They should pipeline directly into Snowflake and use it on their storage. So, the cost is a big issue because these are small to medium size companies, and that is the biggest thing we had to price point for them.

The biggest conversion problem we've seen so far is when someone had a large number of stored procedures that were SQL-based, as opposed to external stored procedures written in C or whatever the DBMS would support. Converting those stored procedures either to a SQL script or to a stored procedure or function that's based on JavaScript is the biggest challenge that most people we've dealt with are having. That's because they have to relearn the language they're writing their logic in.

I would easily rate it an eight out of 10.