Cloud Parts

Firebolt

A cloud data warehouse built for low-latency, high-concurrency queries behind apps and dashboards, also free to self-host as Firebolt Core.

Type
Commercial product
Made by
Firebolt Analytics Inc.
License
Proprietary. Firebolt Core, the free self-hosted engine, ships as binaries only under the Elastic License 2.0 (source-available terms, not OSI open source; a custom licence before July 2025). SDKs, dbt adapter and Kubernetes operator are Apache 2.0
Facts checked
6 October 2026

What it is

Firebolt keeps table data in object storage (S3 in the managed service) as immutable files called tablets, each sorted on the table’s PRIMARY INDEX. A sparse index with one entry per granule of 8,192 rows lets a scan binary-search to the few granules that can match, and every compute node caches the tablets it reads on local SSD. Compute comes as engines: an engine is one or more clusters of S, M, L or XL nodes, and any engine can query any database, so loading and serving can run on separate engines over the same data. Two features target the latency of repeated, app-style queries: aggregating indexes, which precompute a GROUP BY and are updated in the same transaction as the base table, and caching of subresults such as join hash tables across queries. The SQL dialect follows PostgreSQL, and the engine also reads Iceberg tables in place.

The managed service runs in six AWS regions and bills engines per second in Firebolt Units (FBUs): a storage-optimized S node is 8 FBUs an hour, and compute-optimized nodes, with smaller SSD caches, are half that. On the Standard edition an FBU costs $0.23 an hour in US regions, so an S node is $1.84 an hour; Enterprise adds multi-cluster auto-scaling, PrivateLink and HIPAA at $0.35 per FBU. Storage is passed through at S3 cost, $27.07 per TiB-month in US East. Firebolt Core, launched in June 2025, is the same query engine as a free Docker image for laptops or your own clusters, under the Elastic License 2.0, which forbids offering it as a hosted service. In 2026 Firebolt’s site describes the engine as open source “in preview”, but the source repository its build guide points to is not public.

Why teams pick it

  • Built for many concurrent, repetitive queries: aggregating indexes stay consistent with every write, and subresult caching reuses work across queries
  • Engines scale up (node type), out (nodes) and for concurrency (clusters) online, and several engines can share one copy of the data
  • PostgreSQL-compliant SQL, including its error behaviour, rather than a vendor dialect
  • The same engine runs free on a laptop or your own hardware as Firebolt Core, with no usage limits
  • Reads Iceberg tables in place and can mount whole catalogs (REST, Glue, Unity, Snowflake Open Catalog) as databases

Watch out for

  • Not open source today: Core is a closed binary under the Elastic License 2.0, and the announced open-source release was still a preview with a waitlist in October 2026
  • Engines bill while running, and AUTO_STOP defaults to 20 minutes of idle time; L and XL nodes need a request to support
  • Deleted data keeps costing storage for a fixed 7-day recovery window that can’t be changed
  • The managed service is AWS only, in six regions; multi-cluster auto-scaling and PrivateLink need the Enterprise edition at about 50% more per FBU
  • Fast queries depend on choosing primary and aggregating indexes well; a filter on a transformed column or outside the index keys reads much more data

Alternatives

What all real-time analytics databases have in common →

How it fits with other technologies

An engine, a table sorted for its filters, and an aggregating index the planner uses automatically · sql

CREATE ENGINE IF NOT EXISTS serving WITH
  TYPE = S FAMILY = STORAGE_OPTIMIZED NODES = 2
  MIN_CLUSTERS = 1 MAX_CLUSTERS = 1 AUTO_STOP = 5;
USE ENGINE serving;

CREATE TABLE page_views (
  tenant_id  INT,
  viewed_at  TIMESTAMP,
  page       TEXT,
  user_id    BIGINT,
  load_ms    INT
) PRIMARY INDEX tenant_id, viewed_at;

CREATE AGGREGATING INDEX page_views_daily ON page_views (
  tenant_id, DATE_TRUNC('day', viewed_at), page,
  COUNT(*), COUNT(DISTINCT user_id), SUM(load_ms)
);

-- served from page_views_daily, not by scanning page_views
SELECT page, COUNT(*) AS views
FROM page_views
WHERE tenant_id = 42
GROUP BY page
ORDER BY views DESC
LIMIT 10;

Node types and list prices#

Standard edition, US regions, per node per hour, billed per second while the engine runs. Checked 6 October 2026.

Node typeStorage-optimized: vCPU, RAM, SSD cacheStorage-optimized priceCompute-optimized price
S8 vCPU, 64 GB, 1,875 GB$1.84 (8 FBU)$0.92 (4 FBU)
M16 vCPU, 128 GB, 3,750 GB$3.68 (16 FBU)$1.84 (8 FBU)
L32 vCPU, 256 GB, 7,500 GB$7.36 (32 FBU)$3.68 (16 FBU)
XL64 vCPU, 512 GB, 15,000 GB$14.72 (64 FBU)$7.36 (32 FBU)
  • An engine costs node price × nodes × clusters. Enterprise is $0.35 per FBU in the US; outside the US, Standard is $0.28 and Enterprise $0.42. Committed-use discounts go through sales.
  • The pricing calculator lists a compute-optimized S node with 8 vCPU, 16 GB of RAM and a 475 GB SSD cache.
  • Storage is $27.07 per TiB-month in US East, US West and Ireland, $28.84 in Frankfurt and $29.43 in Singapore and Mumbai. New accounts get $200 in credits.

Ways to run it#

Managed service

Standard, Enterprise, Dedicated

Firebolt runs engines and storage in its AWS account in six regions. Dedicated adds single-tenant infrastructure; its price is by quote.

Firebolt Core

free, Elastic License 2.0

The same query engine as a multi-arch Docker image, from one laptop to a multi-node cluster. Needs Linux 6.1 or newer for io_uring; queries go over HTTP on port 3473. Can’t be resold as a hosted service.

Kubernetes operator

self-managed, 2026

Apache 2.0 operator and Helm chart that run engines, a metadata service backed by PostgreSQL and a gateway in your own cluster, over S3, GCS or Azure Blob Storage.

See it in a real stack

No architecture uses Firebolt yet. Drop it into the playground and wire it up yourself.Open playground →

Benchmarks

How to read a benchmark →
Where it came from2019–2026

Eldad Farkash, Saar Bitner and Ariel Yaroshevich had built the BI company Sisense, where cloud data warehouses struggled with terabytes of data behind interactive dashboards. They founded Firebolt in 2019 to make warehouse queries fast and cheap enough for user-facing workloads, and came out of stealth in December 2020 with $37 million.

Writing a warehouse from scratch would have taken years, so the team assembled one and had production customers in under 18 months. The runtime was a hard fork of ClickHouse, chosen for its vectorised speed and basic scale-out. The SQL parser and planner started from Hyrise, an academic database from HPI, because it was also C++ and simple to extend, and the logical plan was redesigned along the lines of Apache Calcite. Firebolt then replaced ClickHouse’s distributed execution with its own shuffle-based stages and rewrote most functions to behave like PostgreSQL.

A $100 million Series C in January 2022 valued the company at $1.4 billion, and Mosha Pasumansky joined from Google BigQuery as CTO. In June 2025 Firebolt released Firebolt Core, the engine as a free download, and said it kept it closed so it couldn’t easily be copied; its licence became the Elastic License 2.0 that July.

Why it’s built this way

Fork the ClickHouse runtime instead of writing one
ClickHouse was fast, battle-tested and already did basic distributed queries, which let a small startup ship quickly. A hard fork left Firebolt free to change interfaces and replace whole layers later.
Planner and runtime in the same language
Much database work happens where planner and runtime meet. With a C++ runtime, a C++ planner (from Hyrise rather than Java-based Calcite) let engineers work across both without switching stacks.
PostgreSQL semantics over ClickHouse’s dialect
PostgreSQL is widely known, close to ANSI SQL and raises errors early, for example on overflow. Matching it meant overhauling scalar and aggregate functions without giving up vectorised speed.
Maintain aggregating indexes in the same transaction
Apps run the same aggregations constantly. Updating precomputed groups incrementally on every write moves work from reads to writes, so reads after a commit never hit a stale or recomputing index.

Timeline

  1. 2019

    Founded by former Sisense executives

  2. 2020

    Leaves stealth in December with $37 million

  3. 2022

    $100 million Series C at a $1.4 billion valuation

  4. 2024

    Describes rebuilding the forked runtime for PostgreSQL compliance

  5. 2025

    Firebolt Core released in June; Elastic License 2.0 from July

  6. 2026

    Kubernetes operator published; open-source engine announced as preview

Sources21 · facts checked 6 October 2026

Improve this page on GitHub