Hacker News Reader

Comment by avinassh | Hacker News Reader

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

View on HN

Will you release the code into the public domain, like SQLite?

absolutely not.

We're not fans of public domain, which is one of the things that led us to create libSQL in the first place.

It is MIT.

Why not do both? Release as public domain or MIT license. Take your pick.

The MIT license requires you to attribute the original authors, I would assume.

What's wrong with public domain?

Public domain rights differ across countries. So someone could put a work into the public domain and sue you in the one or two major countries where copyright can’t be disclaimed by the original author without a license, or where there isn’t legal precedent for it (this is purely theoretical and has never actually occurred before, it would also not be likely to succeed if it did happen).

Also, it is technically possible for someone to claim public domain software as entirely their own work, while MIT requires attribution.

Do you honestly believe any of the SQLite authors or its millions of users (especially deep-pocketed companies like Apple) lose any sleep at night over this?

No. It’s only really an issue in theory.

Is your company a member of the SQLite Consortium? https://www.sqlite.org/consortium.html

> 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

I assume this will need to change the shared memory header protocol so either SQLite comes along for the ride or this is an incompatible ABI?

So a hard fork?

What is meant by a 'hard fork'? Are there different kinds of forks?

To me, a "hard" fork is one where you plan not to maintain any compatibility with your upstream and not to share any future code in either way (neither from original to fork nor back). "Soft" forks often retain a degree of compatibility, and some future developments can be shared.

(In this case, since it's a rewrite in Rust, it's not actually a fork at all, I think)

Got it! Thanks.

The kinds that keep file format compatibility?

Or are they claiming they will support MVCC with full file format and interprocess synchronization compatibility.

Got it! Thanks.

How much has Turso raised so far? Rewriting SQLite sounds like it may cost a sum.

Crunchbase says 7M seed: https://www.crunchbase.com/organization/chiselstrike

Reply on news.ycombinator.com