HN Reader

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

[1] https://github.com/tursodatabase/turso

Also is this a single file DB? If so is the format stable?

    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

Some comparison to another embedded SQL DB, i.e. sqlite3, would be useful. How abusable is it? What tradeoffs are taken? Etc.

    /// Create a new empty row
    pub fn new() -> Self {
        Self { values: Vec::new() }
    }

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

https://news.ycombinator.com/item?id=46234806

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.