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

Append-only has many other benefits, including zero contention between many readers and (single) writers. In the vanilla version, writers still contend though.

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

    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

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

Note to owner: CI is broken.

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.

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

It's an entirely new project that happens to have some compatibility with one of the popular SQL databases, namely SQLite.

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

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.

It's the Rust superiority complex that's subtly speaking thru the Rust "rewrite" projects. Of course rust is better so why would anyone want to stay on the old, C-coded version?

Turso a third party project that has nothing to do with SQLite.

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.

1. having such a huge local SQLite file that migration to another format is unfeasible;

2. bottlenecking on a single specific metric that happens to be more performant in Turso;

3. ready to introduce another programming language and its build toolchain into the project;

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

I've been trying to think of what other meaning they could have gone for but got nothing. Stoo lap? Sto olap?

i am guessing its a joke?

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

In fact it looks like a generic comment I'd write and come back to later.

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

Stoolap: we index your shit

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.

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.

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