Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build your own SQLite in Rust, Part 5: Evaluating queries

blog.sylver.dev

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#21

Post by sejje »

usrbinbash wrote: post #19
rockwotj wrote: post #3

Earlier quoted context omitted.

SQLites alternative in rust is a thing though https://github.com/tursodatabase/limbo

"alternative" implies that this is either on a comparable level of battle-testedness and feature completeness as sqlite, or that it solves problems that sqlite has, or that is delivers substantiable, or at least noticeable advantages over sqlite. So, which of these points apply?

I don't think it implies any of that.

I think it means you might use it in similar situations. Like when you want an in-memory database.

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#22

Post by whstl »

mamcx wrote: post #20
mmiao wrote: post #5

Making a basic database that works is not hard, but making a robust one is really hard. What makes SQLite shines is its extensive testsuite. I still don't understand the motivation of limbo, as without years of hardwork on test you can't say you are correct, and why i should pay for it...

> without years of hardwork on test you can't say you are correct Before, I have the myth in my head that RDBMS development is like cryptography/kernels: Something not mean for humans to do. Now working as part of one ( http://spacetimedb.com ) I see now that is hard, but doable. Certainly MORE EASY than working in ERPs that is the thing that I have done for more than 20 years (now THAT is what is insane). Literally…

This is interesting.

I completely get why SQL is important and as an user I love it as a language, but as an application writer I have a very complicated relationship with it. It requires either inline SQL (which carries its own security risks and causes a bit of redundancy), or we gotta use complex abstractions on top of it, like ORMs. Tests also require spinning up a database or require some extra machinery.

It feels like we're making our lives more complicated by "requiring" a database to have SQL.

I would be totally ok with adopting a non-SQL relational database with a more structured API in greenfield projects. (Btw I will be definitely checking out your company).

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#23

Post by usrbinbash »

sejje wrote: post #21
usrbinbash wrote: post #19

Earlier quoted context omitted.

"alternative" implies that this is either on a comparable level of battle-testedness and feature completeness as sqlite, or that it solves problems that sqlite has, or that is delivers substantiable, or at least noticeable advantages over sqlite. So, which of these points apply?

I don't think it implies any of that. I think it means you might use it in similar situations. Like when you want an in-memory database.

No I might not. In these similar situations, I will use sqlite, unless someone can point out one of the items listed above as a reason to use something else.

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#24

Post by NoahKAndrews »

usrbinbash wrote: post #23
sejje wrote: post #21

Earlier quoted context omitted.

I don't think it implies any of that. I think it means you might use it in similar situations. Like when you want an in-memory database.

No I might not. In these similar situations, I will use sqlite, unless someone can point out one of the items listed above as a reason to use something else.

Just because you don't like it doesn't make it not an alternative. Even if it's objectively worse, it's still an alternative.

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#25

Post by usrbinbash »

NoahKAndrews wrote: post #24
usrbinbash wrote: post #23

Earlier quoted context omitted.

No I might not. In these similar situations, I will use sqlite, unless someone can point out one of the items listed above as a reason to use something else.

Just because you don't like it doesn't make it not an alternative. Even if it's objectively worse, it's still an alternative.

> Just because you don't like it

Read my post again. Sympathy or lack thereof don't factor into this equation. This is about battle-testedness and features. I don't make technical decisions based on emotions.

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#26

Post by mattturck »

Tanjreeve wrote: post #15
tyushk wrote: post #14

Earlier quoted context omitted.

SurrealDB [1] is a fairly complete database written in Rust. I've used it for fairly small web apps and it felt comfortable to work with coming from MongoDB. [1] https://github.com/surrealdb/surrealdb?tab=readme-ov-file

SurrealDB is still really coy on its performance/what it's good at/not good at to adopt for a major data project. There's lots of features but no real indication as to if I could scale them for a dataset of billions of records. I've had my fingers burnt too many times before by products with a big table of tick box features but none of them are really usable (e.g Geospatial data comes up for me a lot) Either you need…

Benchmarking is here: https://surrealdb.com/blog/beginning-our-benchmarking-journe...

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#27

Post by anarki8 »

Animats wrote: post #11

I wish someone would finish a decent database in Rust. At least get it to 1.0 stable and go on from there. - Limbo: "Limbo is a work-in-progress..." - Sled [1]. Not sure what's going on there. Last release 3 years ago, but a constant stream of "alpha" versions that never get released. SQLite with Rust bindings seems to be the go-to system. Depending on C packages is often a headache when cross-compiling, though. [1]…

redb is what are you looking for

https://github.com/cberner/redb

Re: Build your own SQLite in Rust, Part 5: Evaluating queries

#28

Post by Tanjreeve »

mattturck wrote: post #26
Tanjreeve wrote: post #15

Earlier quoted context omitted.

SurrealDB is still really coy on its performance/what it's good at/not good at to adopt for a major data project. There's lots of features but no real indication as to if I could scale them for a dataset of billions of records. I've had my fingers burnt too many times before by products with a big table of tick box features but none of them are really usable (e.g Geospatial data comes up for me a lot) Either you need…

Benchmarking is here: https://surrealdb.com/blog/beginning-our-benchmarking-journe...

That's great they got some out two weeks ago. This has been a couple of years getting here.
Post reply on HN