What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using this solution for three years.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
How was the initial setup?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner