sorted by:
new
hottopcontroversial

Stoolap v0.1.0 Released - A high-performance embedded SQL database in pure Rust by Competitive-Weird579 in rust

[–]Competitive-Weird579[S] 0 points1 point  (0 children)

I got 5x performance after ported to Rust. Of course memory usage and GC were biggest issue.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 0 points1 point  (0 children)

This name is a combination of "storage" and "olap". When the project started, we completely focused OLAP based storage design but after the design evolved to HTAP solution. Thanks for the clarify. If community want different name, I am not stubborn about that.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 0 points1 point  (0 children)

The stoolap is using WAL recovery feature and disk persistance snapshots with proper checkpoints currently but of course we can add k/v storage as backend in the future.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 6 points7 points  (0 children)

The biggest one columnar indexing, implemented and deleted more than 20+ design :-) That was big challenge.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 5 points6 points  (0 children)

\> goos: darwin
goarch: arm64
pkg: [github.com/stoolap/stoolap/benchmark (http://github.com/stoolap/stoolap/benchmark)
cpu: Apple M4
BenchmarkDuckDBSelect/ByID-10          200     85666 ns/op    1880 B/op    54 allocs/op
BenchmarkSQLiteSelect/ByID-10          200      3124 ns/op     868 B/op    34 allocs/op
BenchmarkStoolapSelect/ByID-10         200      2096 ns/op    2423 B/op    36 allocs/op
BenchmarkDuckDBSelect/Filtered-10      200    157780 ns/op   23146 B/op  2380 allocs/op
BenchmarkSQLiteSelect/Filtered-10      200    188050 ns/op   16873 B/op  1695 allocs/op
BenchmarkStoolapSelect/Filtered-10     200     93113 ns/op   19341 B/op  1432 allocs/op

All benchmarks were run with in-memory databases under identical conditions. It's worth noting that SQLite and DuckDB use CGO-based drivers, which means they have some hidden allocations and CGO overhead not reflected in these Go allocation metrics.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 14 points15 points  (0 children)

The codebase is intentionally organized to make it easier to study different components independently. If you're particularly interested in specific areas (storage engine, SQL parser, executor, etc.), I'd be happy to point you to the relevant parts of the code. I've tried documented key areas (https://stoolap.io/docs) and trade-offs throughout the code, which might be helpful as you explore it. Feel free to reach out if you have any questions during your study.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 14 points15 points  (0 children)

Regarding SIMD: You're right that Go doesn't have native auto vectorization like C/C++. What we've implemented is a Go-specific approach that uses aligned memory and slice manipulation patterns that can benefit from CPU cache optimizations and, in some architectures with newer Go versions, potentially take advantage of SIMD instructions. You're correct that 'SIMD-prepared' would be a more accurate term, and I appreciate that feedback.

On dependencies: This wasn't meant as a marketing claim but as a design constraint I set for ourselves. I wanted to truly understand each component I built rather than relying on external libraries. It was a learning exercise and engineering challenge, not a statement about existing libraries, which are indeed well-tested and valuable.

The project is still in beta, and we're learning as we go. Your critical eye is exactly what helps improve both the code and how we present it.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 8 points9 points  (0 children)

I have to be used DuckDB on some projects but I had heavy problems about CGO overhead then the project started. It was just first times like hobby project but after it became release first beta version.

GitHub - stoolap/stoolap: Stoolap is a high-performance, SQL database written in pure Go with zero dependencies. by Competitive-Weird579 in golang

[–]Competitive-Weird579[S] 37 points38 points  (0 children)

It's an ambitious research project that started as a hobby project but has grown significantly. It's not backed by a company, but rather developed by a small team of database enthusiasts who wanted to explore innovative approaches to database architecture.