HN Explorer

20 comments

[ 2.7 ms ] story [ 45.7 ms ] thread
Arcuru
> 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
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.

hansvm
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.
rich_sasha
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 

    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
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".)

sudarshnachakra
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
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
I think the name is not good. It sounds like "stool app". Among other things, "stool" means poo.
DoctorOW
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() }
    }
JohnCClarke
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
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.
kiliancs
I would be interested in seeing numbers backing the high performance claims.
riku_iki
Any benchmarks to compare to sqlite and pg?