Snowflake Reviews

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.

For Snowflake, we had four main use cases. The first use case was related to a data warehouse, and my banking client wanted to move his SQL Server database to Snowflake. All the source systems were also on Oracle and file-based systems, and the target data warehouse was SQL Server. From SQL Server, the client wanted to move to Snowflake. 

The second use case was related to a chat or messaging client. They were using EMR Hadoop as their data warehouse, but it was not performing, so we had to move the EMR Hadoop to Snowflake. 

The third use case was related to a ServiceNow compliance system, where ServiceNow was using SAP HANA for its reporting data warehouse, but it was too slow. It was not performing, and it was causing a lot of problems. We moved that ServiceNow compliance system from SAP HANA to Snowflake.

The fourth use case was related to a huge SQL Server database for a banking client. We moved the entire SQL database to Snowflake. 

Data sharing is a good feature. It is a majorly used feature. The elastic compute is another big feature. Separating compute and storage gives you flexibility. 

It doesn't require much DBA involvement because it doesn't need any performance tuning. We are not really doing any performance tuning, and the entire burden of performance tuning and SQL tuning is on Snowflake.

Its usability is very good. I don't need to ramp up any user, and its onboarding is easier. You just onboard the user, and you are done with it. There are simple SQL and UI, and people are able to use this solution easily. Ease of use is a big thing in Snowflake.

Portability is a big hurdle right now for our clients. Porting all of your existing SQL ecosystem, such as stored procedures, to Snowflake is a major pain point. Currently, Snowflake stored procedures use JavaScript, but they should support SQL-based stored procedures. It would be a huge advantage if you can write your stored procedures using SQL. 

It seems that they are working on this feature, and they are yet to release it. I remember seeing some notes saying that they were going to do that in the future, but the sooner this feature comes out, it would be better for Snowflake because there are a lot of clients with whom I'm interacting, and their main hurdle is to take their existing Oracle or SQL Server stored procedures and move them into Snowflake. For this, you need to learn JavaScript and how it works, which is not easy and becomes a little tricky. If it supports SQL-based procedures, then you can just cut-paste the SQL code, run it, and easily fix small issues. 

I have been using this solution for three years.

So far, with all four clients who have this solution, I have not seen any problem that stands out and causes major headaches or something like that.

Its scalability is really good. You can scale in both ways. You can actually scale up and down or scale out. Scaling up and down is done where we have an extra small warehouse, and we are moving to small, medium, large, or something like that. If you have a query that is running slow or a lot of data you are dealing with is slow, you can scale up. If you want to scale down from large to small, you can do that. 

If you want to get concurrency, scale-out architecture is available. I can actually do a cluster-based architecture where I can have two clusters, three clusters, or something like that. This way the concurrency can be improved.

In terms of the number of users, we have around 200 users.

They have a website where you have to go and raise your tickets. They resolve the ticket, and they are working fine. 

They don't actually entertain emails nowadays because the company has become big. I remember initially interacting with them through email. Now they don't do that. They clearly say not to send emails and go through the ticketing process, which makes sense. For a big company, it is not possible to track emails.

It is not complex. It is straightforward. It is a very simple database anyway. It is just having a script and running them. 

The only thing is that you have to go through the whole nine yards of getting an account or getting your single sign-on enabled. That is a part of every process. For any single sign-on application, you will have to go through this process. 

You also need to involve the right people, such as the security team, infrastructure team, and networking team. When they are there, the setup becomes easier, and there are no problems.

For its maintenance, we have only two or three people. We have one DBA and one account admin. There is another DBA who will take a rotation. You don't really need a big team to manage this because it is all cloud. Management is not that heavy.

Snowflake goes by credits. For a financial institution where you have 5,000 employees, monthly costs may run up to maybe $5,000 to $6,000. This is actually based on the usage. It is mostly the compute cost. Your computing cost is the variable that is actually based on your usage. It is pay-per-use. In a pay-per-use case, you won't be spending more than $6,000 to $7,000 a month. It is not more than that for a small or medium enterprise, and it may come down to $100K per year.

Storage is very standard, which is $23 a terabyte. It is not much for any enterprise. If you have even 20 terabytes, you are not spending more than $400 per month, which may turn out to be $2,000 to $3,000 per annum. 

When comparing it with SAP HANA, there is no one solution that fits all. Snowflake is useful if you have a SaaS-based product such as Salesforce, Workday, Anaplan, and Greenhouse. You can get the data from this type of SaaS-based system and ingest data.

SAP is born out of the entire ERP ecosystem. You have enterprise resource planning, and you have manufacturing, finance, and other systems. Big manufacturing industries usually implement ERPs because they want to do reporting, etc. SAP has this custom box stuff, and it is very difficult to get the data out of your SAP systems. So, you have to use SAP HANA. If you're not using the SAP systems, you don't really need SAP HANA. You are free to go for Snowflake. If you have an ERP system and you need to get the data out and move into an SAP or ERP system, and you want to have a data warehouse actually of ERP system, then SAP HANA makes more sense because it can natively talk to SAP. In such a case, you don't want to go for Snowflake. 

I would advise looking at your environment. Look at the workload and what you are trying to migrate. There is no one size fits all model. If you are a transaction system and you want to go with Snowflake, I would not advise this solution. If you are a reporting system and you want to migrate, Snowflake is the best choice. 

You also need to look at what kind of queries people are running. Don't assume that just because you are moving to Snowflake, you are going to cut down the cost by some factor. That is not going to happen. You need to really do a lot of homework and groundwork to know what kind of queries you're running and how can you avoid the compute costs. There is a lot of metadata available in Snowflake. You have to look at all that and then consciously try to improve the numbers. 

It is definitely a good tool and a good database without any adoption problems. Users who are SQL savvy can immediately adopt this solution. User onboarding is not really a huge exercise. It is a very simple exercise.

I would rate Snowflake an eight out of ten.

I use it for data warehousing. I just design databases, put data in there, and get data out.

Although I haven't used it much, it is very fast and the performance is great.

It has some technical quirks that whoever is using it needs to be aware of. It doesn't enforce typical relational database constraints. If you're not aware of that, you can really put some bad data in there.

I've been using it for about three months.

I would give it a ten out of ten. I haven't seen it failover.

I've never had any issues with it. It is being extensively used. We have between a hundred and a thousand users using Snowflake.

I have not had any experience with customer support, but I've heard it's good.

I've heard it's quite expensive.

I would give Snowflake a seven out of ten.

We use the product as a data warehouse.

The tool is very easy to use. The solution’s desktop features are also very easy to use. Also, the product’s SQL-based connectivity is also good. It can connect with any tool.

Snowflake needs to improve its programming part. Though the tool has Snowpath, it doesn’t support all features like its competitor, Databricks. Snowflake doesn’t support external data ingestion capabilities. You need to have third-party tools for that. Also, the tool needs to incorporate data integration features in its future releases.

I have been working with the solution for two years.

The solution is stable.

The product is scalable. You can scale the solution’s computation and storage features separately.

My company is a direct partner of the product. We have a lot of Snowflake experts who can resolve any doubts. Hence, I haven’t felt the need to contact customer service and support.

The solution’s setup is easy since it's a SaaS product. The tool’s deployment is fast and wouldn’t take more than two minutes.

Snowflake’s pricing is transparent. It is one of the cheapest cloud database warehouse providers. The tool follows a credit cost model. Everything on Snowflake is charged on the basis of credits. The credits depend on the cloud region and the public cloud provider that we use. Hence, the cost per credit will be different for AWS in Frankfurt and AWS in India. I think North Virginia is the cheapest region in terms of cost per credit. You will be consuming around 16 credits for large data warehouses.

I would rate the solution a nine out of ten. Snowflake is the market leader in data warehousing and cloud database. I don’t think that it has a direct competitor. I would suggest you give Snowflake a try if it fits your use case. You can open up a trial version for 45 days and convert it to a regular account. There are different tiers in the solution like business critical, standard, etc. The tool gets updates every week.

We use the solution to migrate data from old legacy ERP systems into Snowflake which reduces our work by 70 percent.

The solution is easy to use. We have third-party integrations, which make it easy to migrate from our landing to our warehouse. Inside Snowflake, we can convert what we create, unlike other hyperscalers.

The price could be improved. The more data we consume, the higher the cost becomes. Our licensing will also increase. How can we use our licensing system effectively? We have expertise and experience in different implementations, and we have control of our licensing. Therefore, there is an accelerator that allows us to control these effective methods of licensing.

I have been using the solution for three years.

We have had no issues with the stability.

I give the scalability an eight out of ten.

The initial setup is not complex.

The solution is costly, making it unsuitable for midsize organizations due to its price.

I give the cost of the solution a seven out of ten.

I give the solution an eight out of ten.

For organizations that do not wish to be confined to one type of hyperscalar, such as VM Azure, I recommend Snowflake as it provides greater flexibility.

We use the solution to support our data infrastructure.

The feature that is really striking is the ability to translate the SQL workloads into the NoSQL version that can be used by Snowflake. We can configure the size of our workloads because Snowflake gives us control over the use of resources and costs.

I have heard people having difficulty with the machine learning model, so there may be room for improvement.

The cost of the solution is high and has room for improvement.

I have been using the solution for over one month.

I give the scalability an eight out of ten.

The solution is expensive but worth the cost because the quality is there.

I give the solution an eight out of ten.

I advise people to do as much research as they can before utilizing the Snowflake.

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.