February 21, 2026
Double bits, double beef
Two Bits Are Better Than One: making bloom filters 2x more accurate
Two Bits, Big Fights: Floe’s smarter filter sparks wow vs déjà vu
TLDR: Floe says a small tweak makes bloom filters catch mistakes twice as well, speeding up database work. Commenters split between “cool math” and “we already had this,” with hardware nitpicks and CS-curriculum jokes proving the real drama—important because faster filters mean cheaper, quicker data jobs.
Floe claims a simple twist—use two bits instead of one—to make a “bloom filter” (a fast, probabilistic bouncer that kicks out obviously wrong data) twice as accurate and speed up SQL joins. Translation: fewer false alarms, less wasted work, faster results. The crowd went full popcorn mode. One camp’s excited—“clever, the math checks out”—while another camp screams old trick and confusing write-up, insisting it’s basically a known “blocked bloom filter” rebranded. The vibe is equal parts “neat hack” and “we’ve seen this before.”
Skeptics like vlmutolo argue it’s a roundabout reinvention of an existing approach that improves memory locality, while ozgrakkurt dropped receipts with links to Parquet and RocksDB, suggesting the two bits should be made more independent. Meanwhile, hardware nitpickers jumped in with, “why not 64-bit?” and spun up a micro-optimizations fight that reads like a tiny civil war over integers. And in a surprisingly wholesome twist, newbies admitted the concept never came up in school—one confessed it’s “triggering my imposter syndrome.”
So yes, Floe’s pitch is shiny—and it might cut tons of useless decompression and probing—yet the comments are the real show: praise, déjà vu, and spicy gatekeeping. Curious? Peek the GitHub or the FloeSQL tag while the thread keeps roasting and cheering in equal measure.
Key Points
- •Bloom filters are used in Floe to speed up SQL queries by eliminating non-matching rows early.
- •Floe applies Bloom filters in two places: storage engine (before decompression) and hash joins (before probing).
- •An adaptive pushdown mechanism builds the filter from the join’s build side and performs first-pass checks on minimal columns.
- •Filtering is dynamically enabled/disabled based on observed row-skip statistics to avoid unnecessary overhead.
- •A worked example shows large decompression savings for low-match joins, and the article claims 2x fewer false positives with their method.