Kore: Binary File Format Optimized for Modern Data Systems (Open Source)
arunkore2026
11 points
9 comments
May 30, 2026
Related Discussions
Found 5 related stories in 94.4ms across 8,961 title embeddings via pgvector HNSW
- Kimi K2.6: Advancing open-source coding meetpateltech · 628 pts · April 20, 2026 · 54% similar
- Kimi K2.6: Advancing Open-Source Coding nekofneko · 39 pts · April 20, 2026 · 50% similar
- TorQ: Kdb+ Production Framework tosh · 30 pts · May 22, 2026 · 46% similar
- NumKong: 2'000 Mixed Precision Kernels for All ashvardanian · 39 pts · March 20, 2026 · 45% similar
- Why does C have the best file API maurycyz · 95 pts · March 01, 2026 · 45% similar
Discussion Highlights (6 comments)
arunkore2026
A binary file format built from first principles for modern data systems. Parse 100MB 50x faster than JSON, with 50-70% better compression. Full language support (Python, Java, JavaScript, Go, C#, Ruby). Includes a VS Code extension for viewing .kore files. 3 years of production testing before open source release.
theginger
What does it do better than parquet? The compression ratio quoted is lower than parquet but I expect higher to be better in this context
microflash
> The fastest, most compressed columnar format for big data How large a dataset can it tackle? I work with Parquet files spanning 300million+ records (~800MB files) using DuckDB and it works within seconds. I might be interested to see benchmarks against Parquet and Vortex. A DuckDB extension would be great as well.
arpadav
looks like a cool project, but id say keep working on it since there seems to be some confusion on why someone would want to use this: no benchmarks and overall pretty vibe-codey (which id personally be very hesitant to use in production) another comment already mentioned comparison to vortex, which is the same compression ratio and same speeds as youre claiming - but your compression is half of parquet. and if speed is the main goal youre going for, python is an interesting choice. no hate, but def keep working on it, and would love to see more concrete benchmarks with various columnar store types
miohtama
How it achieves the performance? What is the tradeoff?
saulpw
47 releases in 3 weeks. Dozens of meaningless cruft files committed at the project root, like "h .kore_fileformat_source_v0.1.0.zip -Algorithm SHA256" with a summary of "less" commands. 19 deployments, all failed. A+++ pure slop. If there's any value in this repo, I couldn't find it after a cursory examination, and I'm not willing to expend the effort to continue looking.