Firebolt Reviews

My main use case for Firebolt is primarily for using SQL and complex designs, and I mainly use it to deliver sub-second, high-content analytical queries on massive data sets for real-time dashboards.

A specific example of how I use Firebolt for those real-time dashboards is that Firebolt powers our sub-second dashboards with petabytes of ad click data, delivering millisecond metrics.

In addition to my main use case, Firebolt also powers real-time SaaS product analytics, fraud detection, and multi-tenant IoT telemetry processing.

Firebolt has positively impacted my organization by reducing query latency to milliseconds, lowering cloud compute costs, and accelerating executive decision-making.

I can share specific outcomes, including that computing using Firebolt reports up to 400x faster queries, 77% lower storage costs, and 40 to 70% operational savings.

From my point of view, Firebolt's best features are separate indexing, multi-tag querying, sub-second queries, decoupled compute, and price-performance optimization.

Of those features, I rely the most on sparse indexing in my daily work because it scans minimal data blocks, directly speeding up queries while reducing cloud costs.

One small detail I appreciate about Firebolt is that its aggregation index stands out by pre-computing repetitive metrics, ensuring instant, sub-second dashboard rendering.

Regarding Firebolt's AI capabilities, I think it enforces enterprise-grade governance and security through granular role-based control and compliance frameworks, access governance, data protection, and enterprise compliance.

Regarding Firebolt's AI capabilities, I find that it ensures high AI output reliability by serving as an ultra-low latency and deterministic SQL engine for Retrieval-Augmented Generations (RAG), and its sub-second sparse indexing queries and execution ground external AI models in accurate relational data without hallucinating raw calculations.

Key areas where Firebolt can be improved include its ecosystem connectors and integrations, as expanding out-of-the-box native integrations for wider ETL tools, data orchestration platforms, BI, and enterprise connectors would be beneficial.

Firebolt's sparse indexing requires careful manual schema tuning, creating a learning curve for teams, which is something I would consider a needed improvement.

Beyond performance tuning, connector depth is a key area for improvement for Firebolt, including ad-hoc query flexibility, as queries without primary and aggregation indexes incur higher compute scans, making unpredictable ad-hoc workloads slower than structured dashboard queries.

I have been using Firebolt for the last year.

Firebolt's scalability is great.

Whenever I need customer support, they politely handle and resolve all my issues.

Firebolt's customer support is great, as they consistently handle and resolve all my issues whenever I need assistance.

I would rate the customer support on a scale of 1 to 10 as a nine.

Before adopting Firebolt, my data engineering teams running large-scale sub-analytical workloads typically relied on traditional cloud data warehouses such as Snowflake, Amazon Redshift, and Google BigQuery, and we switched because those solutions bottlenecked on high compute costs and query latency for high-concurrency, sub-second dashboards.

Data-driven enterprises using Firebolt typically achieve ROI across three primary areas: cloud infrastructure savings, engine and productivity gains, and query performance improvements, and I can specifically share that we see cloud compute savings of 40% to 70% due to Firebolt's reliance on sparse and aggregation indexing, which prunes irrelevant data blocks before scanning.

Firebolt's pricing, setup, and licensing structure offers simplicity, transparency, and predictability with minimal startup friction, and there are no upfront license fees or setup costs, allowing deployment directly via cloud marketplaces into managed workspaces.

Before committing to Firebolt, we evaluated common alternatives falling into three distinct categories: Snowflake, Amazon Redshift, and Google BigQuery, as well as specialized real-time analytics engines like ClickHouse and Apache Druid, which execute raw, dedicated speed but demand higher operational overhead.

I would rate Firebolt overall as an 8.5.

I chose an 8.5 for my rating because I think there are some minimal changes that could improve Firebolt more.

Firebolt is deployed in my organization as a managed SaaS public cloud, which is a standard deployment hosted and fully managed across AWS, GCP, and Azure.

I mostly use AWS as my primary cloud provider with Firebolt.

For teams considering Firebolt, I advise evaluating suitability, optimizing setup, and maximizing ROI, emphasizing the importance of matching the right workload, as Firebolt excels as a specialized engine for high-concurrency, low-latency analytical applications of customer-facing dashboards.

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.

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.

I have used Firebolt for two months.

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.

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.

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.

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.