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

Limbo: A complete rewrite of SQLite in Rust

turso.tech

Post reply on HN
Print view View original

11–20 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#11

Post by alserio »

edweis wrote: post #6

I am not sure how feasible it is, but can't SQLite be partially rewritten step by step on the main branch instead of being forked? As the article mentioned, a complete rewrite will not be as stable as the original.

what do you mean with "on the main branch"? i doubt that migrating from c makes sense for their constraints and expertise, you would not want someone to come into your house and change your furniture. forking is the right political and technical approach for this team. also rust does not support a lot of sqlite target platforms

Re: Limbo: A complete rewrite of SQLite in Rust

#13

Post by cryptonector »

toenail wrote: post #2

Dunno. Good luck to them, but I never saw a need to rewrite sqlite.

I do see a need for multiple implementations of SQLite3. First there's the need for multiple implementations for the reasons given by the LibSQL folks, second there's the need for a memory-safe language implementation of SQLite3, and third there's the need for a native language implementation for languages whose runtimes really want not to have C involved (e.g., Go).

Re: Limbo: A complete rewrite of SQLite in Rust

#14

Post by bpicolo »

edweis wrote: post #6

I am not sure how feasible it is, but can't SQLite be partially rewritten step by step on the main branch instead of being forked? As the article mentioned, a complete rewrite will not be as stable as the original.

SQLite is open-source but not open-contribution – they don't accept contributions of that sort. They follow "cathedral" style development and invented a whole alternative to git for that purpose https://fossil-scm.org/home/doc/43c3d95a/www/fossil-v-git.wi...

https://www.sqlite.org/copyright.html

> In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to suggest a change and you include a patch as a proof-of-concept, that would be great. However, please do not be offended if we rewrite your patch from scratch.

Re: Limbo: A complete rewrite of SQLite in Rust

#15

Post by jsheard »

AlotOfReading wrote: post #7
xray2 wrote: post #5

I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?

The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.

Related: https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...

C libraries aren't automatically the fastest option, there's a lot of C code which has stagnated on the performance front but is still widely used because it's battle tested and known to be robust by C standards.

Re: Limbo: A complete rewrite of SQLite in Rust

#16

Post by eimrine »

avinassh wrote: post #8

disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo

> It uses Asynchronous I/O

Can it have more than 1 writer?

Re: Limbo: A complete rewrite of SQLite in Rust

#17

Post by Ne02ptzero »

AlotOfReading wrote: post #7
xray2 wrote: post #5

I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?

The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.

> Executing cargo bench on Limbo’s main directory, we can compare SQLite running SELECT * FROM users LIMIT 1 (620ns on my Macbook Air M2), with Limbo executing the same query (506ns), which is 20% faster.

Faster on a single query, returning a single result, on a single computer. That's not how database performance should be measured or compared.

In any case, the programming language should have little to no impact on the database performance, since the majority of the time is spent waiting on io anyway

Re: Limbo: A complete rewrite of SQLite in Rust

#18

Post by xyc »

cryptonector wrote: post #13
toenail wrote: post #2

Dunno. Good luck to them, but I never saw a need to rewrite sqlite.

I do see a need for multiple implementations of SQLite3. First there's the need for multiple implementations for the reasons given by the LibSQL folks, second there's the need for a memory-safe language implementation of SQLite3, and third there's the need for a native language implementation for languages whose runtimes really want not to have C involved (e.g., Go).

The fact that there's no alternative implementation of SQLite also seems to play a part in preventing standardization of WebSQL.

https://www.w3.org/TR/webdatabase/

"The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path."

Re: Limbo: A complete rewrite of SQLite in Rust

#19

Post by avinassh »

eimrine wrote: post #16
avinassh wrote: post #8

disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo

> It uses Asynchronous I/O Can it have more than 1 writer?

As of now it has a single writer, same like SQLite. But we plan to add MVCC with multiple writers in the future. Pekka has experimented with MVCC earlier: https://github.com/penberg/tihku
Post reply on HN