[HN Gopher] Stoolap: High-performance embedded SQL database in p...
___________________________________________________________________
Stoolap: High-performance embedded SQL database in pure Rust
Author : murat3ok
Score : 101 points
Date : 2025-12-12 00:28 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Arcuru wrote:
| > Time-Travel Queries: Query historical data at any point in
| time:
|
| The example here looks like it may be storing the full history of
| transactions? Is that right? That's a pretty high cost to pay for
| something that's not touted as a marquee feature.
|
| I'm working on a DB[1] that stores full transaction history but
| it's so that I can support decentralized synchronization. It's in
| service of my marquee feature so I need to pay the cost of
| storing history, but I'm surprised that Stoolap also seems to be
| doing it for a local embedded database.
|
| [1] https://github.com/arcuru/eidetica
| rich_sasha wrote:
| I would imagine (but haven't looked at it at all) that it's a
| byproduct of an append only data format. Then having a
| historical PoV is cheap - you simply disregard changes after a
| certain time.
|
| Append-only has many other benefits, including zero contention
| between many readers and (single) writers. In the vanilla
| version, writers still contend though.
| rich_sasha wrote:
| Looks very interesting!
|
| Some comparison to another embedded SQL DB, i.e. sqlite3, would
| be useful. How abusable is it? What tradeoffs are taken? Etc.
| seg_lol wrote:
| Initial release: Stoolap - A Modern Embedded SQL Database in Pure
| Rust Stoolap is a high-performance embedded SQL
| database featuring: Core Features: -
| Full ACID transactions with MVCC (READ COMMITTED & SNAPSHOT
| isolation) - Cost-based query optimizer with adaptive
| execution - Parallel query execution via Rayon -
| 101+ built-in functions (string, math, date/time, JSON,
| aggregate, window) - Multiple index types: B-tree, Hash,
| Bitmap (auto-selected or explicit) - Multi-column
| composite indexes - WAL + snapshots with crash recovery
| SQL Support: - JOINs (INNER, LEFT, RIGHT, FULL OUTER,
| CROSS) - Subqueries (scalar, IN, EXISTS, correlated)
| - Common Table Expressions (WITH and WITH RECURSIVE) -
| Window functions (ROW_NUMBER, RANK, LAG, LEAD, etc.) -
| ROLLUP, CUBE, GROUPING SETS - Temporal queries (AS OF
| TIMESTAMP/TRANSACTION) - Views, RETURNING clause, ON
| DUPLICATE KEY UPDATE 104K lines of Rust | No C
| dependencies | Full documentation at stoolap.io
| jdub wrote:
| What an impressive release!
|
| It makes me very curious.
|
| Delivered to GitHub fully-formed: A grand total of 9 commits
| (mostly docs and CI fixes), all in the last 5 hours, and v0.1.0
| released 3 hours ago.
|
| No external database/storage-layer dependencies, so it's not
| "just" a CLI/server/parser wrapper around other libraries doing
| the "real work".
|
| It appears to have a substantial test suite (76% code coverage,
| not skipping the scary bits), and great documentation.
|
| There's a bit of context on https://github.com/stoolap but not
| much else about the author, project goals, relationship to other
| systems, e.g. it could be the data layer for something else.
|
| (Interestingly, there's an archived stoolap-go repo with a very
| similar Go implementation of a columnar/hybrid database, so this
| is not the author's "first draft".)
| forgotpwd16 wrote:
| Can assume they worked on this last few months when they
| stopped development in the, now archived, Go attempt, but they
| scrapped the entire git history on publication. Still, even if
| consider heavy AI use, looks like they put quite the effort in
| this.
| esafak wrote:
| I too am curious how to the first commit came about:
| https://github.com/stoolap/stoolap/commit/768eb836de0ff072b8...
|
| Note to owner: CI is broken.
| murat3ok wrote:
| The Go version was my first attempt. Hit some performance walls
| I couldn't solve cleanly, so I rewrote the whole thing in Rust
| over the past 6 months. Got about 5x speedup and the
| concurrency story is way better with ownership.
|
| The git history thing honestly my commits were a mess after
| months of work. Dead ends, experiments, "fix fix fix" commits.
| Figured I'd start clean for release. In hindsight, probably
| should have kept the ugly history looks less suspicious than
| one big commit.
|
| Goal is basically SQLite but with real MVCC and analytical
| features (window functions, parallel queries). Something you
| can embed but that doesn't choke on concurrent writes or
| complex queries.
|
| Community kill me here but other side thank you for the
| positive comment here.
| Sytten wrote:
| In the same area, I am tracking the Rust rewrite of sqlite by
| Turso [1]. The big advantage is the file format compatibility.
|
| [1] https://github.com/tursodatabase/turso
| egorfine wrote:
| It's _not_ a _rewrite_ of SQLite in Rust.
|
| It's an entirely new project that happens to have some
| compatibility with one of the popular SQL databases, namely
| SQLite.
| forgotpwd16 wrote:
| From the devs themselves[0]:
|
| > _Our goal_ is to build a _reimplementation of SQLite_ from
| scratch, _fully compatible at the language and file format
| level_ , with the same or higher reliability SQLite is known
| for, but with full memory safety and on a new, modern
| architecture.
|
| And they call it rewrite in a recent followup post[1].
|
| [0]: https://turso.tech/blog/introducing-limbo-a-complete-
| rewrite...
|
| [1]: https://turso.tech/blog/we-will-rewrite-sqlite-and-we-
| are-go...
| egorfine wrote:
| They may call it all they want. It's been common between
| some Rust developers to steal valor by highjacking the name
| of original project for their own fun rewrites.
|
| Turso a third party project that has nothing to do with
| SQLite.
| forgotpwd16 wrote:
| Ah, it was about the usage of _rewrite_ by such third-
| party efforts. In this case, yes, the original
| _reimplementation_ (could have also call it _alternative_
| ) wording is probably better. Was confused at the
| "happens to have some compatibility" part because the
| project was started with that intent so it wasn't a
| coincidence.
| egorfine wrote:
| It's not a reimplementation either. It's just a separate
| project which has nothing to do with SQLite. Thus
| mentioning it as "SQLite re _something_ " is not fair.
|
| SQLite compatibility at file level is a nice perk which I
| am not totally convinced is truly needed at all. Like,
| it's hard to imagine scenarios where this is useful. But
| it can be.
|
| Anyway, godspeed. Just don't steal valor.
| lazylester wrote:
| "...hard to imagine scenarios where [file-level
| compatibility] is useful" what am I missing? Surely
| dropping a more performant dbm into an existing project
| would be the application? No?
| lucideer wrote:
| The wording & framing of these things is an interesting
| topic in the context of the W3C's decision to drop WebSQL.
|
| A "rewrite" softly implies a replacement (intent that
| SQLite users would all migrate to Turso eventually & SQLite
| would cease to exist as a project). This isn't the strict
| definition of a rewrite but the implication is there in the
| language.
|
| OTOH the W3C shut down that spec because it required
| competing implementations to exist. This imagines a world
| where Turso & SQLite coexist actively.
|
| E.g. micropython isn't a rewrite of cpython even though
| they both target compatible python, Chrome isn't a rewrite
| of Firefox even though they both target a range of
| compatible languages & formats (but Firefox was a rewrite
| of Netscape - the word depends heavily on context).
|
| I realise this usage isn't coming from you, it's coming
| from the Turso devs themselves, but it does feel like an
| overstep on their part.
|
| The Turso guys can use whatever words they like in their
| blogposts, they're not the authority on whether it
| constitutes a rewrite.
| sudarshnachakra wrote:
| Does this support concurrent writers (unlike sqlite)? Quite an
| impressive feature set for a one-person project.
|
| Also is this a single file DB? If so is the format stable?
| edf13 wrote:
| Sounds very interesting - I've used SQLite in a few Rust based
| projects where performance was the deciding factor... a perf
| comparison with this would be very useful
| dash2 wrote:
| I think the name is not good. It sounds like "stool app". Among
| other things, "stool" means poo.
| duttish wrote:
| Yea, my first association was stool -> poo.
|
| I've been trying to think of what other meaning they could have
| gone for but got nothing. Stoo lap? Sto olap?
| bronlund wrote:
| SQL Tool something something?
| bronlund wrote:
| SQL Transactional Objects OnLine Analytical Processing. My
| best guess so far.
| kolektiv wrote:
| Another voice basically begging them to change the name here,
| yeah. It might be quite interesting as a tool, but please...
| dominotw wrote:
| they are even highlighting a in green after stool to break the
| word into stool.
|
| i am guessing its a joke?
| DoctorOW wrote:
| Comments especially feel vibe coded. Not necessarily bad, just
| not something I would trust with prod data. ///
| Create a new empty row pub fn new() -> Self {
| Self { values: Vec::new() } }
| Klonoar wrote:
| This particular bit doesn't scream vibe-coded to me at all.
|
| In fact it looks like a generic comment I'd write and come back
| to later.
| bronlund wrote:
| Bold name choice.
| skylurk wrote:
| I read it as stool lab...
|
| _Stoolap: we index your shit_
| JohnCClarke wrote:
| Excited for this! A couple of questions:
|
| 1. What is the resolution of timestamps (milli-, micro-, nano-
| seconds)? 2. Any plans for supporting large data BLOBs (e.g.
| PostgreSQL TOAST)? This would open up a lot of use cases and
| would be really interesting to make compatible with the in-memory
| emphasis for the atomic data types.
| kekqqq wrote:
| The project is very new, with two days of unique days with
| commits and 11 commits in its history. I would bet it is
| vibecoded.
| jdub wrote:
| Don't let "AI" make you jump at shadows. Maybe, but probably
| not.
|
| The first commit was pretty fully-formed, which without "AI"
| glasses on just means someone did a whole bunch of work before
| exposing/releasing their work.
| andrewl wrote:
| As a big fan, and user, of SQLite, this looks like something to
| watch. And I agree with the comments about the unfortunate name.
| Just yesterday there was a post here about bad names for
| software:
|
| https://news.ycombinator.com/item?id=46234806
| kiliancs wrote:
| I would be interested in seeing numbers backing the high
| performance claims.
| GlacierFox wrote:
| Stoolap? Sounds disgusting.
| riku_iki wrote:
| Any benchmarks to compare to sqlite and pg?
___________________________________________________________________
(page generated 2025-12-12 23:02 UTC)