back

by pella·10mo ago·view on hn ↗
Turso:

https://algora.io/challenges/turso "Turso is rewriting SQLite in Rust ; Find a bug to win $1,000"

------

- Dec 10, 2024 : "Introducing Limbo: A complete rewrite of SQLite in Rust"

https://turso.tech/blog/introducing-limbo-a-complete-rewrite...

- Jan 21, 2025 - "We will rewrite SQLite. And we are going all-in"

https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...

- Project: https://github.com/tursodatabase/turso

Status: "Turso Database is currently under heavy development and is not ready for production use."

1 comments
sqlite3 has one (apparently this is called "the amalgamation") c source file that is ~265 kloc (!) long with external dependencies on zlib, readline and ncurses. built binaries are libsqlite3.so at 4.8M and sqlite3 at 6.1M.

turso has 341 rust source files spread across tens of directories and 514 (!) external dependencies that produce (in release mode) 16 libraries and 7 binaries with tursodb at 48M and libturso_sqlite3.so at 36M.

looks roughly an order of magnitude larger to me. it would be interesting to understand the memory usage characteristics in real-world workloads. these numbers also sort of capture the character of the languages. for extreme portability and memory efficiency, probably hard to beat c and autotools though.

I don't think the SQLite authors actually edit the single giant source file directly. Their source control repository has the code split up into many separate files, which are combined into "the amalgamation" by a build script: https://github.com/sqlite/sqlite/tree/master/src
yeah i saw that afterwards. they do it to squeeze more optimization out of the compiler by putting everything in one compilation unit. given the prominence of the library i have to wonder if this was an input to zig's behind-the-scenes single compilation unit design choice...