CECerthas·Jul 16, 2026
That's the idea behind the future file format:
https://github.com/future-file-format/F3
Bundle a wasm decoder as a fallback when native decoder isn't available.
In SQLite should have (Rust-style) editionsfuture-file-format
F3
Rust2025–2026
future-file-format / F3
F3
[SIGMOD 2026] F3: The Open-Source Data File Format for the Future
6Distinct people
7Mentions
0Explicit recommenders
784GitHub stars
What to know before exploring
What it is
[SIGMOD 2026] F3: The Open-Source Data File Format for the Future
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month7 dated mentions
Observed mentions: 2025-10-02 01:51:39 UTC to 2026-07-16 09:30:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Oct 2025 | 2025-10-01 00:00:00 UTC | 2025-11-01 00:00:00 UTC | 2 | 0 | 2 |
| Nov 2025 | 2025-11-01 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2025 | 2025-12-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2026 | 2026-01-01 00:00:00 UTC | 2026-02-01 00:00:00 UTC | 1 | 1 | 0 |
| Feb 2026 | 2026-02-01 00:00:00 UTC | 2026-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2026 | 2026-03-01 00:00:00 UTC | 2026-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2026 | 2026-04-01 00:00:00 UTC | 2026-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2026 | 2026-05-01 00:00:00 UTC | 2026-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2026 | 2026-06-01 00:00:00 UTC | 2026-07-01 00:00:00 UTC | 3 | 1 | 2 |
| Jul 2026 | 2026-07-01 00:00:00 UTC | 2026-08-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesIt appears as though the WASM decode returns two values -- one indicating the data type as a primitive value, and a second value being the data buffer
Then there is a helper in this case to de-serialize, "primitive_array_from_buffers()"
https://github.com/future-file-format/F3/blob/bd92506447dc13...
In F3Nice! The world can always use a better data format.
I think you might get some traction if you post the advantages over parquet and other files directly on the readme, so that if someone goes to https://github.com/future-file-format/f3 the see why they should try it.
Mention the advantages and post metrics. Cherry pick the metrics! There's probably a good use case for this but, from the current readme, it's not clear who should use this and why.
In F3F3: The Open-Source Data File Format for the Future
2 points · Open discussionIt took me a while to find the source code, but it's available here:
https://github.com/future-file-format/F3
In F3: Open-source data file format for the future [pdf]The backstory is complicated. The plan was to establish a consortium between CMU, Tsinghua, Meta, CWI, VoltronData, Nvidia, and SpiralDB to unify behind a single file format. But that fell through after CMU's lawyers freaked out over Meta's NDA stuff to get access to a preview of Velox Nimble. IANAL, but Meta's NDA seemed reasonable to me. So the plan fell through after about a year, and then everyone released their own format:
→ Meta's Nimble: https://github.com/facebookincubator/nimble
→ CWI's FastLanes: https://github.com/cwida/FastLanes
→ SpiralDB's Vortex: https://vortex.dev
→ CMU + Tsinghua F3: https://github.com/future-file-format/f3
On the research side, we (CMU + Tsinghua) weren't interested in developing new encoders and instead wanted to focus on the WASM embedding part. The original idea came as a suggestion from Hannes@DuckDB
Read the rest
to Wes McKinney (a co-author with us). We just used Vortex's implementations since they were in Rust and with some tweaks we could get most of them to compile to WASM. Vortex is orthogonal to the F3 project and has the engineering energy necessary to support it. F3 is an academic prototype right now.
I note that the Germans also released their own fileformat this year that also uses WASM. But they WASM-ify the entire file and not individual column groups:
→ Germans: https://github.com/AnyBlox