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".)
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.
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.
>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].
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.
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.
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.
It's not a reimplementation either. It's just a separate project which has nothing to do with SQLite. Thus mentioning it as "SQLite resomething" 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.
"...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?
> 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.
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.
I think their point is that system timestamps for that append-only format aren't good enough. You need logical timestamps corresponding to increasing transaction ids.
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
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.
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:
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.
I generally like—and write—these types of doc comments myself. It just looks nicer in docs/intellisense.
I'm a big proponent of "everything public should have a doc comment," even if it's a short sentence. Doesn't hurt to have it. I never understood people who are allergic to comments.
The fact LLMs add comments is one of the few non-sloppy things they do, IMO
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".)
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.
Yay, glad you found the discussion (well, the good bits), and thanks for the answer. It's cool work!
Very interesting. Roughly speaking, how does performance compare to SQLite?
I too am curious how to the first commit came about: https://github.com/stoolap/stoolap/commit/768eb836de0ff072b8...
Note to owner: CI is broken.
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.
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
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.
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...
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.
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.
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.
It's not a reimplementation either. It's just a separate project which has nothing to do with SQLite. Thus mentioning it as "SQLite resomething" 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.
"...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?
> 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
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.
I think their point is that system timestamps for that append-only format aren't good enough. You need logical timestamps corresponding to increasing transaction ids.
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
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.
I think the name is not good. It sounds like "stool app". Among other things, "stool" means poo.
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?
SQL Transactional Objects OnLine Analytical Processing. My best guess so far.
SQL Tool something something?
Another voice basically begging them to change the name here, yeah. It might be quite interesting as a tool, but please...
they are even highlighting a in green after stool to break the word into stool.
i am guessing its a joke?
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.
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.
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
Bold name choice.
I read it as stool lab...
Stoolap: we index your shit
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.
Comments especially feel vibe coded. Not necessarily bad, just not something I would trust with prod data.
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.
I generally like—and write—these types of doc comments myself. It just looks nicer in docs/intellisense.
I'm a big proponent of "everything public should have a doc comment," even if it's a short sentence. Doesn't hurt to have it. I never understood people who are allergic to comments.
The fact LLMs add comments is one of the few non-sloppy things they do, IMO
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?
I would be interested in seeing numbers backing the high performance claims.
Any benchmarks to compare to sqlite and pg?
Stoolap? Sounds disgusting.