For the past couple of weeks, I've been co-working on SlothDB - an open-source embedded analytical database engine in C++20. Think DuckDB, but with some things I always wished DuckDB had. Why I chose to work on it: Every time I used DuckDB in real life, I hit the same 3 problems: → Extensions broke on every upgrade → Error handling was impossible (free-form strings, no codes) → No GPU acceleration for large-scale analytics So I cowrote my own. From scratch. Zero external dependencies. What SlothDB does differently: 1. GPU Acceleration (CUDA + Metal) — 20-100x faster on datasets with 100K+ rows. Your M1 Mac can now crunch analytics on the GPU. 2. Extensions never break — Stable C ABI. An extension built for v1.0 works on v2.0. No more "please rebuild all extensions after upgrading." 3. Structured error codes — Every error has a numeric code that's stable across versions. Write error handling once, never fix it again. 4. 7 file formats built-in — CSV, Parquet, JSON, Arrow, Avro, Excel, SQLite. No extensions to install. Just: SELECT * FROM 'report.xlsx' 5. QUALIFY clause — Snowflake's best feature. Filter window functions without subqueries. By the numbers: - 130+ SQL features - 325 tests, 131,000+ assertions - Zero external dependencies - Single-file persistence (.slothdb) - Runs on Windows, Linux, macOS Try it in 10 seconds: GitHub: https://github.com/SouravRoy-ETL... The hardest part wasn't the SQL parser or the vectorized execution engine. It was making the file format readers work cross-platform with zero dependencies. Parsing Parquet files without Apache Arrow? That was fun.

SlothDB

Embedded analytical database engine built in C++

Embedded analytical database engine built in C++

Forum Threads

We're launching SlothDB - what file format do you struggle with the most?

Forum Threads

We're launching SlothDB - what file format do you struggle with the most?