ON THIS PAGE
## Architecture
The biggest difference among cloud data warehouses are whether they separate storage and compute, how much they isolate data and compute, and what clouds they can run on.
| Feature | Firebolt | Redshift |
|---|---|---|
| Separation of storage and compute | Yes, separation of storage and metadata as well as compute from compute with full workload isolation. | RA3 instances enable separation of compute and storage, but limited workload isolation compared to other platforms |
| Supported cloud infrastructure | AWS (GCP coming soon) & anywhere (Firebolt Core) | AWS only |
| Isolated tenancy – option for dedicated resources | • Multi-tenant metadata layer • Isolated tenancy for compute & storage per client | • Isolated tenant & resources • Runs in your VPC |
| Control vs abstraction of compute | Uses engine abstraction: • Each engine has configurable cluster size (1-128 nodes) for horizontal scaling. • Configurable compute family (compute vs storage optimized) and type (XS, S, M, L, XL) for vertical scaling • Number of clusters for concurrency (auto)scaling. Provides full workload isolation across engines. | • Configurable cluster size • Configurable compute types |
| Self-hosted and hybrid deployment options | • Firebolt Core: Forever free, self-hosted edition with full query engine capabilities • Same performance and features as managed service • Deploy anywhere: local laptop, cloud, datacenter, Kubernetes • Production-grade distributed architecture • No usage restrictions except building competing SaaS | Limited hybrid options with Redshift Serverless |
| ACID Compliance and Transactions | • Full ACID compliance with snapshot isolation • Multi-statement transactions supported • Strong consistency across all operations • Supports concurrent reads and writes • Transactional integrity for data applications | ACID compliant at table level with some limitations on concurrent operations |
Firebolt is built on a natively decoupled storage & compute architecture, on AWS only. Data has to be copied outside of your VPC into the Firebolt, where both your compute and data run in a dedicated and isolated tenant. A "Firebolt Engine" can be granularly configured across # of nodes and different CPU/RAM/SSD combinations
Redshift has the oldest architecture, being the first Cloud DW in the group. Its architecture wasn't designed to separate storage & compute. While it now has RA3 nodes which allow you to scale compute and only cache the data you need locally, all compute still operates together. You cannot separate and isolate different workloads over the same data, which puts it behind other decoupled storage/compute architectures. Redshift runs as an isolated tenant per customer, and unlike other cloud data warehouses, it is deployed in your VPC. Redshift offers a serverless option which is based on an abstracted unit called Redshift Processing Unit (RPU) ranging from 8 to 512 in increments of 8. Each RPU provides 2 vCPU and 16GB RAM. Thus, 8 RPU is equivalent to 16 vCPU / 128GB RAM. The minimum RPU is 8.
## Scalability
There are three big differences among data warehouses and query engines that limit scalability: decoupled storage and compute, dedicated resources, and continuous ingestion.
| Feature | Firebolt | Redshift |
|---|---|---|
| Elasticity – Scaling for larger data volumes and faster queries | Granular cluster resize with node types, number of nodes and number of clusters. Zero downtime. | Available via Elastic Resize – slow and limited, downtime required |
| Elasticity – Scaling for higher concurrency | A single engine can handle hundreds of concurrent queries. Engines auto-scale the number of clusters up and down base on resource usage thresholds. Idle engines scale down to zero billing. | • 5 concurrent queries per WLM queue by default (up to 8 queues) • Concurrency Scaling enables thousands of concurrent queries |
Firebolt can handle the largest data volumes and concurrency on a single comparable cluster size, thanks to its superior hardware efficiency. Thanks to its decoupled storage & compute architecture it scales very well to large data volumes. However, resizing an engine size isn't instant and requires orchestration if avoiding downtime is necessary. A single Firebolt engine can support hundreds of concurrent queries, avoiding the need to scale out for most use cases. Scaling horizontally for even higher concurrency is manual.
Redshift is limited in scale because even with RA3, it cannot distribute different workloads across clusters. While it can scale to up to 10 clusters automatically to support query concurrency, it can only handle a maximum of 50 queued queries across all clusters by default.
## Performance
Performance is the biggest challenge with most data warehouses today. While decoupled storage and compute architectures improved scalability and simplified administration, for most data warehouses it introduced two bottlenecks; storage, and compute. Most modern cloud data warehouses fetch entire partitions over the network instead of just fetching the specific data needed for each query. While many invest in caching, most do not invest heavily in query optimization. Most vendors also have not improved continuous ingestion or semi-structured data analytics performance, both of which are needed for operational and customer-facing use cases.
| Feature | Firebolt | Redshift |
|---|---|---|
| Indexes | • Sparse primary indexes • Aggregating indexes • Join indexes • Optimizer driven index usage | None |
| Compute tuning | SQL defined engines. Control number of nodes, node family and type per cluster, with one or more clusters per engine. Multiple engines isolate workloads. | Choice over number of nodes and their type |
| Storage format | Columnar, sorted & compressed & sparsely indexed storage (F3 – Firebolt File Format) with native Apache Iceberg support | Columnar & compressed storage (RA3 nodes) |
| Table-level partition & pruning techniques | • User-defined table-level partitions are optional. • Data is automatically sorted, compressed and indexed into F3 format. • Pruning at indexed data-range level. | • No table partitions • User-defined distribution & sort keys are used to optimize for speed |
| Result cache | Yes, results and sub-results cache with transactional spoiling. | Yes |
| Warm cache (SSD) | Yes, at indexed data-range level granularity | Only with RA3 nodes at partition-level granularity |
| Support for semi-structured data & JSON functions within SQL | Yes, including Lambda expressions and native nested array structures | Limited |
| Vector Search and AI Capabilities | • Native vector search capabilities and embeddings • MCP Server for AI driven analytics • Natural Language to SQL • SQL based Inference | Limited AI capabilities – primarily through integrations |
| Query Optimizations | • Primary indexes, aggregating indexes, join indexes, sparse indexes • Sub-plan result caching • F3 storage format optimization • Automatic query optimizer with aggressive pruning • Late column materialization • Query analysis tools based on execution telemetry | • Basic query optimizer • Materialized views • Result caching • ANALYZE for table statistics • Workload management (WLM) • Automated materialized views (AutoMV) • AI-driven scaling (Serverless preview) |
Firebolt is the fastest when it comes to query performance when compared to cloud data warehouses and services like Athena. Its unique approach to storage and indexing results in highly aggressive data pruning that scans dramatically less data compared to other technologies. While other technologies scan partitions or micro-partitions, Firebolt works with indexed data ranges, that are significantly smaller. In addition, Firebolt lets user accelerate queries further with multiple index types (Aggregating index, Join index), and using its decoupled storage & compute architecture workloads can be easily isolated to guarantee consistent performance.
Redshift does provide a result cache for accelerating repetitive query workloads and also has more tuning options than some others. But it does not deliver much faster compute performance than other cloud data warehouses in benchmarks. Sort keys can be used to optimize performance, but their contribution is limited. There is no support for indexes, and low-latency analytics at large data volumes is hard to achieve. Because Redshift decoupling of storage & compute is limited compared to other cloud data warehouses, it doesn't support isolating workloads, which means performance can degrade under pressure and competition for resources.
## Use cases
There are a host of different analytics use cases that can be supported by a data warehouse. Look at your legacy technologies and their workloads, as well as the new possible use cases, and figure out which ones you will need to support in the next few years.
| Feature | Firebolt | Redshift |
|---|---|---|
| Low-latency dashboards | • 120ms query latency at 4000 QPS (FireScale benchmark 2025) • Sub-second performance at TB+ scale with proper indexing • Built for AI-driven analytics, dashboards, and real-time analytic applications | • Seconds to tens of seconds load times at 100s of GB scale • Can achieve faster performance with Concurrency Scaling and proper tuning |
| Enterprise BI | • Growing ecosystem with focus on modern BI tools • Strong SQL compliance with PostgreSQL • Wire level compatibility drives expansion to PostgreSQL BI and ETL ecosystem | • Mature and comprehensive Enterprise DW feature set • Extensive integrations with Enterprise BI ecosystem • Strong AWS ecosystem integration |
| Data Apps and AI Applications (Customer-facing low-latency high concurrency) | • 120ms latency at 4000+ QPS proven performance at TB+ scale • Supports hundreds to thousands of concurrent queries on single engine • Price-performance leader (8x better than Snowflake, 18x vs Redshift) • Purpose-built for AI agents and data-intensive applications • Native vector search and embeddings | • 5 concurrent queries per WLM queue by default (up to 8 queues) • Concurrency Scaling enables thousands of concurrent queries • Seconds-level response times typical • Automatic scaling for burst workloads • Limited AI application support |
| Ad hoc | • Excellent performance out-of-the-box with engine optimized for star and snowflake joins and aggregations • Self learning query plan optimizer • Full workload isolation prevents ad-hoc complexity from affecting real-time workloads • Aggregating indexes are automatically used by optimizer | • Performance dependent on predefined distribution & sort keys • Elastic Resize enables adding compute resources • Typically subset of data loaded for ad-hoc analysis |
Firebolt stands out by being the fastest cloud data warehouse when compared to Snowflake, Redshift, BigQuery and Athena. It's great for delivering sub-second analytics at scale, while remaining hardware efficient and high concurrency friendly. This makes it a great choice for operational use cases and customer-facing data apps. Given that it is not as feature-rich and integration rich as the more mature data warehouses makes it a lesser fit for a general-purpose Enterprise data warehouse. It is also not the best fit for ad-hoc use cases, because of the need to predefine indexing at the table level.
Redshift was originally designed to support traditional internal BI reporting and dashboard use cases for analysts. As such, it is typically used as a general-purpose Enterprise data warehouse. With deep integrations into the AWS ecosystem, it can also leverage AWS ML service, making it also useful for ML projects. However, given the coupling of storage & compute, and the difficulty in delivering low-latency analytics at scale, it is less suited for operational use cases and customer-facing use cases like Data Apps. The coupling of storage and compute, together with the need to predefine sort & dist keys for optimal performance, make it challenging to use for Ad-Hoc analytics.