TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
1–10 of 37 posts
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#2What’s the bottleneck at that point? That number seems small even when stacked up against much slower examples.
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#3Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#4If I’m reading this right, the insertion benchmark for TrailBase C# is hitting about 4.4k inserts of relatively small records per second per core. What’s the bottleneck at that point? That number seems small even when stacked up against much slower examples.
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#5If I’m reading this right, the insertion benchmark for TrailBase C# is hitting about 4.4k inserts of relatively small records per second per core. What’s the bottleneck at that point? That number seems small even when stacked up against much slower examples.
A few observations:
- Both benchmark driver and server are running locally on my laptop, completely saturating the machine.
- I've managed to achieve higher throughput with rust. At least part of it is probably that the client side is lighter on my already saturated machine.
- I've found that I'm getting roughly 3x the performance on a pretty humble 8700G desktop.
- I've found the file-system to have a non-trivial impact.
- The benchmark is only as fast as the bottleneck 50cm in front of the screen managed to make it run. The benchmark driver is here: https://github.com/trailbaseio/trailbase-benchmark/tree/main.... Dotnet is super swift, so I'd be surprised if it couldn't be further optimized (whereas Dart and Node are fairly client-side bottlenecked).
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#6what am I missing at the first benchmark? why is there no comparison to pocket base in golang (the language pocket base is written in, and is allowing extensions to be written in)?
Would it be faster? Maybe, I found that the dart and JS clients didn't reach their theoretical min latency of 3-5ms, so I'm inclined to believe that there's some bottlnecking on the server-side. I'd be very happy to be wrong on this.
From your perspective, would it make sense to just compare the respective dart and JS clients?
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#7It is nice to see more backends utilizing SQLite. The benchmarks and the Comparisions section also seem well done.
Just a nitpick - list the versions of the tested platforms.
Based on your benchmarks repo it looks like that the tests were done against PocketBase [0]: https://github.com/pocketbase/benchmarks
[1]: https://pocketbase.io/docs/go-overview/#custom-sqlite-driver
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#8Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#9(Disclaimer: I'm PocketBase author) It is nice to see more backends utilizing SQLite. The benchmarks and the Comparisions section also seem well done. Just a nitpick - list the versions of the tested platforms. Based on your benchmarks repo it looks like that the tests were done against PocketBase [0]: https://github.com/pocketbase/benchmarks [1]: https://pocketbase.io/docs/go-overview/#custom-sqlite-driver
Hey thanks for chiming it. Huge fan of PocketBase, has been a major inspiration :applause:. For anyone driving by, certainly a more mature product.
- Based on your benchmarks repo it looks like that the tests were done against PocketBase You're right. I did run v0.22.21, which simply was current when I ran the benchmarks first. I absolutely will add the information, rerun, and thanks for the pointers. Glad to hear you got such a boost :clap:
Re: TrailBase: Sub-millisecond open-source application base with Rust, SQLite and V8
#10Looks interesting, might play with it and the C# client soon, do you plan to build a LINQ provider eventually or keep the APIs similar across client languages?
Naively, I would argue that being idiomatic in the respective ecosystem is more important than perfect consistency. Only few users will likely use 2 or more languages and probably even then there's a balance to be struck.