/
.webp)
Generated by Master Biographer | Source for LinkedIn Content
There is a particular species of frustration that only exists at the seam between two layers of a technology stack. Not the frustration of building something broken. The frustration of building something that works perfectly, and still watching it fail — because the layer beneath it refuses to keep up.
Eldad Farkash lived in that frustration for fourteen years.
As co-founder and CTO of Sisense, one of Israel's most successful business intelligence companies, Farkash spent over a decade building analytics products. Not databases. Analytics products. The kind of thing an enterprise pays for because someone in the C-suite needs a dashboard that answers questions about customers, revenue, and operations in real time. Sisense built the visualization layer, the query layer, the user interface. They built everything users touched.
And every performance problem they could not solve lived one layer lower, in a place Farkash did not control.
Snowflake came along and made the operations easier. BigQuery came along and removed the infrastructure burden. Amazon Redshift was already there, scalable, reasonable. But none of them made the fundamental problem go away: the warehouse was slow. Not catastrophically slow — slow enough. Slow enough that ad bidding systems could not use it in real time. Slow enough that user-facing analytics dashboards showed spinners for two or three seconds before loading. Slow enough that Farkash's team had spent years building workarounds — aggregation layers, pre-computed caches, materialized views — all to compensate for the latency that lived in the tier below.
At some point in 2019, the frustration curdled into a decision.
He had spent fourteen years watching the problem. He was going to spend the next decade fixing it.
Sisense was founded in 2004 in Tel Aviv — a five-founder company in the middle of Israel's first serious tech boom. Farkash served as CTO. His co-founder on the go-to-market side was Saar Bitner, who became Sisense's GM and CMO. Ariel Yaroshevich was also part of the core team. Three of the people who would go on to build Firebolt spent roughly fifteen years inside the same company, watching the same problem from different vantage points.
The Sisense business model created an unusual form of institutional knowledge. Sisense sold analytics to enterprises — but it did not sell databases. It sat on top of databases. This meant that every time a customer complained about performance, the root cause was never Sisense's code. It was the query engine in Snowflake, or Redshift, or whatever warehouse sat underneath. Farkash could optimize Sisense's caching. He could pre-aggregate data at the application layer. He could optimize the SQL that Sisense sent to the warehouse. He could not fix the warehouse. That was someone else's product.
By the time Sisense reached unicorn status — a billion-dollar valuation — Farkash had a clearer view of the analytics database problem than virtually anyone who had actually built databases. He had spent years as the most frustrated user of every major data warehouse on the market.
That specific frustration — user-side, not builder-side — shaped every choice Firebolt would make.
Bitner saw the same ceiling from the commercial side. When you are selling analytics software and the demo slows down because the warehouse is taking four seconds to return a query, you cannot fix the demo. You cannot explain the architecture. You just watch the customer's face change. Both Farkash and Bitner carried that specific humiliation out of Sisense and into the founding of Firebolt.
They left together, in 2019, to fix the layer they could never touch.
To understand why Firebolt emerged from Tel Aviv and not San Francisco, you have to understand what Israel has built over the past thirty years — and why it keeps producing database and analytics companies specifically.
Israel has roughly 9 million people. It has roughly 7,000 active tech startups. Per capita, it has more startups than any country in the world. More NASDAQ-listed companies than the UK and Germany combined. It is not an accident.
The structural reason starts with Unit 8200 — Israel's elite military signals intelligence unit. Unit 8200 is often called Israel's NSA, and the comparison is fair in scale and mission, but it understates what it means for the technology ecosystem. Nearly half of Israeli startup founders whose companies were acquired for more than $100M in the last decade served in military intelligence units. The average acquisition value of companies led by Unit 8200 alumni exceeds $317 million. Alumni-founded companies include Wiz (acquired by Google for $32 billion, the largest cybersecurity acquisition in history), Check Point Software, CyberArk, Palo Alto Networks' Israeli predecessor technologies, and hundreds of others.
What makes Unit 8200 different from other military technical programs is the problem type. Intelligence work is adversarial, real-time, and data-intensive. You are not building payroll software. You are building systems that must ingest continuous streams of signals, correlate them in real time, surface anomalies instantly, and do all of this at a scale where a missed pattern has consequences measured in lives. The engineering skills this requires — high-throughput ingestion, low-latency query, fault-tolerant distributed systems — are exactly the skills that produce great database engineers.
Whether Farkash, Bitner, or Yaroshevich served in Unit 8200 specifically is not publicly documented. But the Sisense-to-Firebolt lineage sits inside a broader Israeli database and analytics cluster that shows this fingerprint repeatedly. Wix uses ClickHouse — and some of the Israeli engineers who first adopted ClickHouse at Wix helped spread it across the Tel Aviv ecosystem. Redis was built by Salvatore Sanfilippo in Italy, but the company (Redis Labs) was founded in Tel Aviv and went through the same investor networks. Datorama — an Israeli data analytics platform — was acquired by Salesforce for $800M. Sisense itself was one output of this ecosystem. Firebolt is the next.
There is also a second structural factor: the recycled-founder network. Israeli startups tend to stay Israeli. When a company exits or reaches scale, its founders do not retire. They start the next company, backed by investors who funded the last one, hiring engineers who worked at the company before. Farkash and Bitner did exactly this — they had Bessemer Venture Partners lead their $37M Series A based in large part on what Sisense had become. The same network that funded Sisense's early stages saw the Firebolt founding team and opened the checkbook within months of the company being announced.
The density matters. In a small country with mandatory military service that funnels enormous engineering talent through intelligence work, the feedback loops are short. The Israeli ecosystem does not produce one Snowflake every twenty years. It produces a cohort of data infrastructure companies, nearly simultaneously, all aware of each other, all building on the technical foundation the previous generation established.
When Farkash looked at Snowflake and BigQuery in 2019, he did not see bad engineering. He saw engineering that made different tradeoffs than the ones he needed.
Snowflake's architecture — the one that made it the fastest-growing enterprise software company in history at its 2020 IPO — was built around a few core ideas: separate storage from compute so you can scale them independently, use cloud object storage (S3, GCS, Azure Blob) as the persistence layer, and virtualize the compute layer into "virtual warehouses" that can be spun up, paused, and resized on demand. The result was operationally elegant. Any analyst could query petabytes of data without managing infrastructure. The cost model was pay-per-query, not pay-per-cluster. Enterprise IT loved it.
The tradeoff: Snowflake's architecture is optimized for elastic scale and operational simplicity, not raw query latency. When you execute a query against Snowflake, the system scans its micro-partitions — small chunks of columnar data stored in S3 — and uses zone maps (min/max metadata per partition) to skip irrelevant partitions. This is efficient for batch analytics and internal BI where a query taking two seconds is acceptable. It is not efficient for a system serving 1 million ad auction analyses per second, where two seconds means millions of dollars of lost bid decisions.
Firebolt made five architectural bets that deviate from the Snowflake approach:
Bet 1: Sparse Primary Indexes (index, don't scan).
Firebolt's primary index is sparse — one entry per 8,192 rows (a "granule"), stored in a compact structure alongside the data in Firebolt's proprietary F3 file format. When a query arrives with a predicate — WHERE user_id = 12345, WHERE timestamp BETWEEN X AND Y — Firebolt uses the sparse index to identify exactly which granules could contain matching rows, and skips everything else. The data read is not "reduced partitions" like in Snowflake; it is "the minimum possible set of rows required to answer the query." This is the difference between Snowflake's philosophy ("scan everything, skip what you can") and Firebolt's ("index everything, read only what you must").
Bet 2: Aggregating Indexes (precompute, don't recompute).
For analytics workloads that repeatedly compute the same aggregations — total revenue by date, impressions by campaign, conversion rates by segment — Firebolt maintains incremental aggregating indexes: precomputed summaries that update automatically as new data arrives. When a query asks for SUM(revenue) GROUP BY campaign_id, the query optimizer routes it to the aggregating index rather than scanning billions of base rows. The customer Bigabid uses this to analyze 1 million ad auctions per second. The 400x query improvement they reported is largely this mechanism at work.
Bet 3: Vectorized Execution + JIT Compilation.
Traditional query engines evaluate SQL row by row, applying filters and transformations to one record at a time. Firebolt's vectorized execution engine processes data in batches of column values — vectors — that are sized to fit in CPU cache lines. This enables SIMD (Single Instruction, Multiple Data) CPU operations: one instruction applied simultaneously to a batch of values, rather than one instruction per value. On top of this, Firebolt uses JIT (just-in-time) compilation, which converts SQL expressions into native machine code at query time. The combination eliminates the interpretation overhead that slower systems carry invisibly in every query.
Bet 4: Tiered Caching with Surgical Precision.
Firebolt nodes maintain SSD-backed local caches. But because the sparse index system means Firebolt reads precisely the data ranges it needs, the cache is populated with surgical precision rather than brute force. Hot data ranges — the granules that get queried repeatedly — stay in cache without requiring manual partitioning strategies or user configuration. The automatic cache warmup feature (introduced in 2025) means that when engines restart, they reload their recent access patterns from S3, achieving full warm-cache performance in 35 minutes rather than waiting through a cold-start period that could last hours under real query load.
Bet 5: Stateless, Disaggregated Architecture with FoundationDB as the Coordination Layer.
This is the most ambitious and least visible bet. Traditional data systems tie transactional state to compute nodes — if a compute node fails mid-transaction, the transaction fails. Firebolt built its transaction coordination layer on FoundationDB (Apple's distributed key-value store, one of the most battle-tested databases ever built). The metadata service manages transaction state centrally, outside the compute layer. This means Firebolt's compute engines are truly stateless — they can be replaced, scaled, or upgraded mid-transaction without interrupting user workloads. It is what allows Firebolt to claim zero-downtime upgrades and sub-second cold starts on compute provisioning.
Firebolt came out of stealth in December 2020 with a $37M Series A led by Bessemer Venture Partners, with TLV Partners and Dawn Capital participating. The announcement was quiet by Silicon Valley standards — a Tel Aviv company entering a market dominated by two American giants (Snowflake and BigQuery) and one AWS product (Redshift).
But the performance claims were not quiet. From launch, the numbers were aggressive:
- 182x faster than competitors on certain workloads (the number used in early marketing)
- Sub-second query latency on terabyte-scale datasets
The six-month stealth period before the Series A was spent validating those numbers with real customers — and the customer profiles told a story. Not enterprises doing monthly financial reporting. Gaming companies. Ad tech platforms. Media analytics providers. Companies where "fast enough" meant under one second, where a query taking three seconds was a product failure, not an inconvenience.
This customer selection was not accidental. Farkash built the product for the workload Sisense had always struggled to serve — customer-facing analytics, the tier of data infrastructure that sits between the warehouse and the end user. The gaming and ad tech companies that became Firebolt's earliest customers were the companies that had simply given up on general-purpose warehouses and were either running custom analytics infrastructure or living with unacceptable latency. Firebolt gave them an off-the-shelf solution that met their performance requirements for the first time.
Six months after the Series A, in June 2021, Firebolt raised $127M in a Series B led by Dawn Capital and K5 Global. The valuation crossed $1 billion — unicorn status, reached in roughly eighteen months of public existence. This was not a typical Silicon Valley trajectory. This was an Israeli database company, operating largely outside the US tech media's attention span, hitting a billion-dollar valuation on the back of a technical product with a narrow but extremely high-value use case.
The most significant hire in Firebolt's history came shortly after, in the lead-up to the January 2022 Series C: Mosha Pasumansky joined as CTO.
Pasumansky's resume is one of the more extraordinary in the database industry. He co-invented MDX — the query language that powers the OLAP cube tools used in Microsoft Analysis Services, and that underpinned a generation of enterprise BI infrastructure. He spent years at Microsoft building SQL Server's analytical engine. He built Bing's distributed storage and processing systems. And then he went to Google, where he spent years as a principal engineer on BigQuery — the team responsible for turning BigQuery from a technically interesting internal project into Google Cloud's highest-revenue data product.
Firebolt hired the architect of the product they were competing against.
This was not corporate maneuvering. Pasumansky was not hired to leak BigQuery's internals — he was hired because he understood, better than almost anyone alive, exactly where the fundamental limits of BigQuery's design were built in. When you have designed a system from first principles, you know which tradeoffs were choices and which were constraints. Pasumansky knew which of BigQuery's latency characteristics were inherent to its architecture, and that knowledge became Firebolt's engineering roadmap.
The $127M Series B closed in June 2021 — five months before ClickHouse, Inc. raised $250M at $2B valuation, and about a year before Databricks raised $1.6B in a round that valued it at $38B. The data infrastructure investment wave was cresting, and Firebolt was riding it.
But the market validation that mattered was not the funding announcement. It was the customer stories that started emerging in 2021 and 2022:
Bigabid — an Israeli ad tech company — analyzed 1 million ad auctions per second. Their previous stack ran on MySQL. MySQL is a transactional database never designed for this workload. The migration to Firebolt delivered 400x query acceleration on 100 million record datasets, and a 77% reduction in storage costs. At the scale Bigabid operated, query latency was not an analytics preference. It was the product. An ad bidding system that takes 50 milliseconds to compute a bid is commercially nonviable — by the time the result comes back, the auction has closed.
Similarweb — the web analytics platform used by marketers to research competitors — put 1 petabyte of production data into Firebolt. The workload: 100 queries per second, continuous, with users analyzing up to 2 years of historical web traffic data at millisecond response times. One petabyte. 100 queries per second. Milliseconds. That is not a benchmark — that is a production system serving paying customers in real time.
IQVIA — a healthcare data giant — used Firebolt to query 1 billion patient records in milliseconds. IQVIA's business depends on making complex queries over enormous healthcare datasets available to pharmaceutical researchers and health system analysts. The previous approach required pre-computing answers to anticipated questions. Firebolt made previously impossible queries routine.
Sweet Security — a cybersecurity platform — ingested 1 terabyte of security event data per day, maintaining sub-second query latency across 350+ continuously updating tables under constant concurrent load. This is the use case where Snowflake's architecture is most exposed: a system that requires simultaneous high-throughput writes AND sub-second analytical reads on the same tables, under load. The two workloads fight for resources in systems not designed for both. Firebolt's engine-isolation architecture — separate compute engines for ingestion and analytics, accessing the same S3-backed storage — made them coexist.
WINGX — an aviation analytics company — processed 168 billion rows of flight data daily, running 70% faster than their previous SQL Server warehouse.
The pattern across these customers was consistent. They were not companies running monthly sales reports for CFOs. They were companies whose products depended on data infrastructure performing at application-tier latency — under 500 milliseconds, consistently, under real concurrent user load. For these companies, Snowflake and BigQuery were not slow competitors. They were architecturally incompatible products.
In 2024, Firebolt's blog published a finding that reframed the entire competitive narrative. Mobile web research consistently shows that users abandon applications that take more than 3 seconds to respond. This is not data engineering trivia. This is product psychology that has been validated across billions of user sessions on mobile devices.
Firebolt's customer Primer, a fintech platform, had measured this directly: switching between data views on their previous system took 3 seconds. They could watch users disengage. After migrating to Firebolt, that latency dropped to milliseconds. The user behavior changed. Engagement went up. The database was a UX problem.
This framing — database performance as user experience design — was the most powerful repositioning Firebolt made. The argument was no longer "Firebolt is faster than Snowflake on benchmarks." The argument was: if your product shows a spinner for 3 seconds, your users are leaving. The thing causing that spinner is your data layer. Firebolt eliminates the spinner.
For companies building customer-facing data applications — analytics embedded in their SaaS products, real-time dashboards their customers use, operational intelligence served directly to users — this was not an abstract technical claim. It was a conversion rate argument.
The January 2022 Series C — $100M led by Alkeon Capital — brought total funding to approximately $270M and confirmed the $1.4 billion valuation. The supporting investor list tells the story of who believed in Firebolt's thesis: Bessemer Venture Partners (one of the most respected enterprise SaaS investors in the world), Dawn Capital (a European deep-tech specialist), Zeev Ventures, TLV Partners, Angular Ventures. The Tel Aviv contingent was heavily represented. These were investors who had seen this founding team operate before.
The speed of the trajectory was remarkable. December 2020: Series A, $37M, out of stealth. June 2021: Series B, $127M, unicorn. January 2022: Series C, $100M, $1.4B valuation. Thirteen months from first public announcement to Series C close at unicorn valuation.
For comparison: Snowflake was founded in 2012 and did not IPO until 2020 — eight years. Firebolt did not need eight years to prove the market existed. The market had been created by Snowflake. Firebolt just had to demonstrate it could serve the part of that market that Snowflake's architecture couldn't reach.
2024 revenue: $40.4 million — up 62% from $24.9M in 2023.
By 2026: approximately 189 employees across 20+ countries, with offices in Tel Aviv, Kirkland (Washington), and Munich. 52% of the team is engineering. The company is engineering-heavy by design — the product competes on architecture, not on sales volume.
The customer base skews toward a small number of high-value accounts rather than a broad SMB motion. This is consistent with the integration complexity: deploying Firebolt for a customer-facing analytics use case requires schema design around Firebolt's indexing model, migration from an existing warehouse, and application-layer changes to target the new system. This is not a plug-and-play migration. The switching cost is real — which means customers who migrate stay migrated, but the sales cycle is long.
In September 2024, Firebolt announced a major architectural expansion: multidimensional scaling, with separate compute engines for data loading, ELT, and low-latency analytics — all running against the same S3-backed storage tier, with full ACID transaction guarantees and global consistency.
This was Firebolt completing the architecture that Farkash had designed from the beginning: not a warehouse you switch to for analytical speed, but a complete data platform that handles every tier of workload simultaneously without one tier degrading another.
The category name they chose: "NewCDW" — new cloud data warehouses. The argument: the generation of cloud data warehouses built in the 2010s (Snowflake, BigQuery, Redshift) optimized for elastic scale and operational simplicity. The next generation must optimize for two simultaneous requirements that the first generation cannot reconcile: batch/internal analytics AND real-time customer-facing data applications. Firebolt's claim was that it was the first product designed to deliver both from a single architecture.
In March 2025, Firebolt published FireScale — their own open benchmark framework, designed to measure the workloads that Snowflake's TPC benchmarks don't simulate: high concurrency, low latency, real user patterns. The FireScale numbers:
- 8x better price-performance than Snowflake
- 18x better than Redshift
- 90x better than BigQuery
The methodology caveat applies: FireScale is Firebolt's own benchmark, run by Firebolt's team, designed around workloads where Firebolt's architectural bets are most advantageous. But Firebolt published the methodology on GitHub. Independent reproduction is possible. And the concurrency numbers — 37.5x less spend required to match Firebolt's performance on Snowflake — are consistent with what Firebolt's own customers report in case studies published by both sides.
Firebolt's positioning exposed a fracture in the cloud data warehouse market that the incumbents have since scrambled to address.
Snowflake introduced a "Search Optimization Service" — essentially a post-hoc indexing layer you pay extra for. BigQuery added BI Engine, a caching layer capped at 100GB. Redshift added AQUA (Advanced Query Accelerator), a push-down acceleration layer. All of these are architectural patches that attempt to solve, at the margins, the latency problem that Firebolt built from the ground up to solve. The incumbents' responses are telling — they validate Firebolt's original thesis. The question is whether "fast enough, eventually" beats "fast by design, always."
The long-term bet Firebolt is making is about the direction of software architecture. As more products become data-intensive — AI agents querying warehouses in real time, SaaS products embedding live analytics for end users, operational systems requiring instant answers at scale — the acceptable latency threshold keeps dropping. The workloads that only Firebolt could serve in 2021 will be the normal workloads of 2026 and 2030. If that bet is right, Firebolt's architecture was not premature. It was early.
1. The founders were not frustrated by their own database — they were frustrated by everyone else's.
Most database companies are founded by database engineers who hit limits in existing technology and decide to build something better from a systems perspective. Farkash and Bitner were BI engineers. They built analytics products that lived on top of warehouses, and they spent fourteen years watching query latency kill Sisense's product demos and customer implementations. They did not found Firebolt because they had a better database theory. They founded it because they were the most frustrated users of every database that existed.
2. The CTO they hired built the product they're competing hardest against.
Mosha Pasumansky co-invented MDX, built Bing's distributed infrastructure, and spent years as a principal engineer on Google BigQuery. Not a consultant who advised on BigQuery. An engineer who built the pieces of BigQuery that Firebolt's benchmarks show it beating. His institutional knowledge of where BigQuery's latency is architecturally inherent — not configurable, not fixable with more compute — became Firebolt's engineering roadmap after he joined in 2022.
3. "Sub-second" is an architectural constraint, not a marketing aspiration.
When Firebolt says sub-second analytics, it means something precise: the combination of sparse indexes (read only the granules the query needs), aggregating indexes (route aggregation queries to precomputed results), vectorized SIMD execution (eliminate interpretation overhead), and tiered SSD caching (keep hot ranges in memory) must produce, together, a result in under one second. Remove any of these components and the guarantee collapses. Sub-second at scale is not one trick — it is five independent optimizations that compound. The system is engineered to the constraint the way aerospace systems are engineered to weight limits.
4. Gaming and ad tech companies are the ideal customers not because they're technologically adventurous, but because they have the clearest business case.
An ad bidding system that takes 50ms too long loses the auction. A gaming analytics platform that takes 3 seconds to load player behavior data is a dashboard no one uses. The business case for sub-second performance in gaming and ad tech is not a nice-to-have — it is directly measurable in revenue. A 10% reduction in query latency translates to 10% more actions completed per user session. These customers cannot rationalize Snowflake's latency profile. Firebolt did not have to convince them the problem mattered. They arrived already convinced. The only question was whether Firebolt could solve it.
5. The $270M raised to produce $40M in revenue may be exactly the right investment structure — and here is why.
A common misreading of Firebolt's capital efficiency: $270M raised, $40M ARR, seems expensive. But Firebolt spent five years building an architecture that required building not just a query engine, but a proprietary file format (F3), a distributed metadata coordination layer (on FoundationDB), a JIT compilation pipeline, a vectorized execution engine, and a completely custom indexing subsystem. None of this could be assembled from open-source parts. It had to be built from scratch, by senior engineers, over multiple years, before the product could be sold at all. The capital-to-revenue ratio reflects the engineering investment required to be architecturally correct, not inefficient go-to-market. If the NewCDW category becomes the default infrastructure for customer-facing data applications as AI agents proliferate, the current revenue figure is a starting point. If it doesn't, Firebolt will have built the fastest warehouse in the world for a niche that stayed niche. Either way, the architecture is real.
Sources: NoCamels (2020, 2022 funding coverage), TechCrunch (Dec 2020, Jun 2021, Jan 2022), Firebolt blog (FireScale, NewCDW, late materialization, auto cache warmup, MERGE statement, OLTP vs. OLAP, transactions architecture, FuzzBerg, Confluent connector), Firebolt comparison pages (vs. Snowflake, vs. ClickHouse, vs. BigQuery), Firebolt case studies (Bigabid, Similarweb, IQVIA, Sweet Security, WINGX, Lurkit, Primer, Dealer Trade Network, TLDCRM, MerchJar), Firebolt knowledge center (whitepapers index), BusinessWire Series B press release, SiliconANGLE, Unit 8200 ecosystem data (various sources). Revenue figures via Getlatka / public filings. Mosha Pasumansky background via ClickHouse and MDX history sources.
