Show HN: Skytable's new NoSQL engine with BlueQL, injection safety, better perf
https://skytable.io/blog/2023/12/skytable-octave-is-here/
Hey HN!I've been working on Skytable since 2020 and after several iterations from a simple K/V store, we've walked the path to this release. The goal of Skytable is to deliver a solid foundation for building data intensive applications.
Skytable's primary goal is performance and scale. Even with a query language it can outperform K/V stores which use simple commands (benchmarks will be shared in another post).
Several implementations in Skytable (especially around query evaluation and execution) are fundamentally different from SQL and even NoSQL counterparts and there are some entirely new concepts which might make it a little hard to grasp.
BlueQL is a very important part of Skytable and it employs some interesting concepts to try and reduce the surface for injection attacks and tries to be a modern and secure alternative to SQL.
- Source code: https://github.com/skytable/skytable
- Documentation: https://docs.skytable.io
- Rust client driver (more client drivers are underway): https://github.com/skytable/client-rust
I'm here for any questions!
-- Sayan
NB: Clustering and Replication will be released around Q1'24. Choice: AP in CAP. The original post has been updated for clarity.
Looking forward to the benchmarks and 1.0!
How does Skytable achieves this? In other words, what makes it different than others?
If you want a more in-depth review you can read https://docs.skytable.io/architecture
That document will be updated frequently!
Does it use a B Tree / LSM / Bitcask? Or something else entirely?
How does your storage engine compare with sled?
The storage section also mentioned that most data stays in RAM and it is planned to change. Is it still the same? The benchmarks were ran on the in-memory version or disk one (if that is changed)
Also, can you share against which all KV Stores the benchmark was done?
The project looks very exciting and I’d love to know more details
Real-time/background compaction and more will be implemented shortly before GA is shipped (this is currently a beta).
Wow, that's very aggressive. It smells to the outside observer like overcorrecting for a real but blown out of proportion problem
But we're just trying to reduce the surface area for mistakes. In the end, one can rest knowing that they didn't at least write vulnerable code, the most common one!