Stoolap: High-performance embedded SQL database in pure Rust

📝 Discussion Summary (Click to expand)

The three most prevalent themes emerging from the Hacker News discussion about the Stoolap database release are:

Cost and Rationale for Storing Full Historical Data: Users questioned the decision to store full transaction/temporal history in an embedded database, noting the high storage cost unless it serves a critical, advertised feature.
- Quote: "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." (Arcuru)
Impressive Scope and Fast, Unconventional Development Timeline: Commenters were highly impressed by the rich feature set (ACID, MVCC, advanced SQL) presented in a pure Rust, dependency-free embedded database, especially given the extremely short commit history leading up to the v0.1.0 release.
- Quote: "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." (jdub)
Concerns Over Naming Convention: A significant portion of the discussion centered on the database's name, which many users associated negatively with bodily functions ("stool").
- Quote: "I think the name is not good. It sounds like 'stool app'. Among other things, 'stool' means poo." (dash2)

🚀 Project Ideas

A governance tool/service that allows new database projects to register potential names (like Stoolap) and checks them against a database of established industry terms, prior project names (including archived ones), and "bad connotation" word lists (like the "stool" issue).
Core value proposition: Providing early feedback on product naming to avoid technical confusion, branding issues, and negative community reception before branding locks in.

Key	Value
Target Audience	New database implementers, open-source project creators, and technical founders launching developer tools.
Core Feature	Real-time fuzzy matching against registered names, English/lingustic conflict checks (e.g., looking up similar sounding words in major languages), and a "developer vibe check" keyword flagging system.
Tech Stack	Node.js/TypeScript (for easy integration and string processing), PostgreSQL for the name registry, simple web UI.
Difficulty	Low

Why HN commenters would love it: Directly solves the community outcry regarding the name "Stoolap" ("I think the name is not good." - dash2; "Another voice basically begging them to change the name here" - kolektiv).
Potential for discussion or practical utility: Could host spirited discussions on developer-tool naming conventions and memorable failures.

A tool that analyzes the underlying data structure (like in Eidetica or Stoolap if append-only) of time-travel capable databases, specifically calculating the storage cost (in terms of redundant historical data) associated with maintaining temporal queries ("AS OF").
Core value proposition: Providing developers transparency and control over the storage overhead incurred by "Time-Travel Queries" in append-only or MVCC systems, enabling proactive optimization.

Key	Value
Target Audience	Developers using embedded/local time-travel capable databases (e.g., Stoolap, Eidetica, or systems leveraging log-structured merge trees).
Core Feature	Ingest database transaction logs/snapshots, model the internal state changes, and output a breakdown chart showing total storage vs. storage required for the current state, highlighting historical storage bloat.
Tech Stack	Rust (for performance and direct interaction with Rust DB internals), WebAssembly (for frontend visualization), D3.js/Plotly.
Difficulty	Medium

Why HN commenters would love it: Directly addresses Arcuru's concern about "high cost to pay for something that's not touted as a marquee feature." It turns the abstract cost of history into a concrete visualization.
Potential for discussion or practical utility: Could become the standard benchmarking tool for comparing the storage efficiency of different append-only database implementations.

A web service that takes user-defined requirements (concurrency needs, typical query profiles, storage limits) and benchmarks them against modern embedded Rust databases (like Stoolap) and legacy SQLite, generating a "Suitability Score" tailored to the user's project context.
Core value proposition: Reducing the friction and guesswork involved in determining if a modern, high-performance embedded solution (like one written in pure Rust) justifies switching away from the ubiquitous SQLite.

Key	Value
Target Audience	Rust developers currently using SQLite in embedded applications who need performance validation (like edf13).
Core Feature	Interactive questionnaire mapping features (ACID, concurrency, JSON support, dependencies) to technical benchmarks, culminating in a direct comparison report (e.g., "Stoolap offers 3x better concurrent write performance but an unstable file format.").
Tech Stack	Python/FastAPI backend, React/Next.js frontend, standardized benchmark harness implemented in Rust for testing Stoolap/Turso.
Difficulty	Medium

Why HN commenters would love it: Directly addresses the desire for "Some comparison to another embedded SQL DB, i.e. sqlite3" (rich_sasha) and addresses performant replacements (Sytten tracking Turso).
Potential for discussion or practical utility: Could foster a community-driven database comparison standard based on real-world use cases.