Firebolt's upserts enable transactional analytics
Product manager at Firebolt on on scaling challenges and ACID compliance in OLAP databases
This is Firebolt staking out the small but valuable slice of analytics where rows must be changed in place, not just appended fast. In practice, that means workloads like order status, account state, or user profile changes can live in the same engine as dashboard queries. ClickHouse is strongest when data arrives as immutable events, logs, or metrics, then gets compacted later, which is why observability fits it so well and transactional analytics is a harder stretch.
-
The concrete difference is how updates are stored. Firebolt says every write goes through a separate metadata layer that tracks the latest state of each row, which is how it delivers ACID behavior. ClickHouse instead writes new parts and cleans old versions up later through background merges.
-
That matters when the data is not just event history. If a customer changes a shipping address or an order number, the application expects one current answer immediately. Firebolt is positioning for those mixed transactional and analytical workflows, while ClickHouse is built first for high throughput analytical reads.
-
The trade off is that ClickHouse still wins plenty of workloads because append heavy systems are simpler and very fast. In interviews, it shows up as the speed layer for logs, real time analytics, and AI retrieval, often alongside Snowflake or Postgres rather than replacing them.
The market is moving toward engines that can do more than scan immutable data, so native updates become a way to win embedded analytics and operational workloads that used to require two databases. ClickHouse should keep dominating event style analytics, while Firebolt and similar systems push to capture the higher value workflows where freshness, correctness, and low latency have to coexist.