Firebolt is fast for analytical purposes. For example, we have analytical data in our data warehouse, and Firebolt can quickly query it to generate quick results. We have a specific catalog for any query, and Firebolt can generate the results much faster than other providers.
Can quickly query it to generate quick results
What is most valuable?
What needs improvement?
Firebolt's engine takes a long time to start because it needs to make engine calls. Currently, the data size of Firebolt is small. It can be increased.
For how long have I used the solution?
I have used Firebolt for two months.
What do I think about the stability of the solution?
The product is stable. Firebolt takes some time to start after a certain amount of idle time, but I have yet to face any bugs. In case of a bug, the only issue is that the engine starting time is a bit high.
What do I think about the scalability of the solution?
The solution is scalable. Our users are companies. We can disclose that our customers are either paid clients or subscription-based. They buy our solutions in-house, and different personas use them. We don't know the number of users per account because our solution is not a website.
Which solution did I use previously and why did I switch?
We have used Snowflake before. We support both. Firebolt has better performance, executing queries much quicker than Snowflake. However, Snowflake has more functionality. Depending on the client's needs, we can recommend the best option. Firebolt is a relatively new technology. Snowflake has many functionalities. Firebolt does not support unloading data to S3. There is no built-in way to do this in Firebolt. Alternatively, the data can be retrieved using API calls and loaded to S3 manually. Data can be unloaded to S3 directly using Snowflake. Firebolt significantly improves our performance over Snowflake because it takes less time to execute queries. This is especially important for our company because we use some KPIs that require fast loading times.
What other advice do I have?
One way to retrieve data from firewalls is to add query parameters to the connection string. For example, you can use the REST API to retrieve the security query. Some firewalls have been deployed to maintain them.
They have a team we can contact if we have any queries or are facing difficulties. They try to solve our issues completely. Maintenance is relatively easy. We handle QA issues from our solution, but I’ve never faced any issues related to the firewall. One thing the firewall didn't have before was the ability to support data in different reviews. Before that, the firewall didn't have query parameters. Based on our requirements, we added a new feature to add query parameters with the connection strength. We can directly specify the connection strength that we want to access data, and we can access it. I suggest using a shared HPE client for all requests to the firewall API. This would save our app a lot of SQL and memory resources. It's a backend-related solution, but it would be a good one. Overall, I rate the solution an eight out of ten.
Which deployment model are you using for this solution?
Public Cloud
