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.
> 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.
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.
jdub|2 months ago
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".)
murat3ok|2 months ago
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.
esafak|2 months ago
Note to owner: CI is broken.
forgotpwd16|2 months ago
Sytten|2 months ago
[1] https://github.com/tursodatabase/turso
egorfine|2 months ago
It's an entirely new project that happens to have some compatibility with one of the popular SQL databases, namely SQLite.
Arcuru|2 months ago
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|2 months ago
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|2 months ago
Some comparison to another embedded SQL DB, i.e. sqlite3, would be useful. How abusable is it? What tradeoffs are taken? Etc.
edf13|2 months ago
dash2|2 months ago
duttish|2 months ago
I've been trying to think of what other meaning they could have gone for but got nothing. Stoo lap? Sto olap?
kolektiv|2 months ago
unknown|2 months ago
[deleted]
dominotw|2 months ago
i am guessing its a joke?
unknown|2 months ago
[deleted]
bronlund|2 months ago
skylurk|2 months ago
Stoolap: we index your shit
seg_lol|2 months ago
kekqqq|2 months ago
jdub|2 months ago
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|2 months ago
https://news.ycombinator.com/item?id=46234806
JohnCClarke|2 months ago
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.
DoctorOW|2 months ago
Klonoar|2 months ago
In fact it looks like a generic comment I'd write and come back to later.
sudarshnachakra|2 months ago
Also is this a single file DB? If so is the format stable?
riku_iki|2 months ago
kiliancs|2 months ago
GlacierFox|2 months ago
huflungdung|2 months ago
[deleted]
ITniggah|2 months ago
[deleted]