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 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."
Guessing the shortcomings become starker if you’re spending lots of time in the codebase/building a company on top of it.
Yeah… Attempting to integrate MVCC and then doing vector search gave enough perspective to do this!
> building a company on top of it.
So be sure you proceed in such a way that never contributes any money or code back to the original project.
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."
I was completely unaware of that! How old is that document? I should reach out.
3 replies →
Indeed! This sort of thing is a problem. It's the same with Internet protocols: you need at least two implementations to get to Standard.
Most of us don't see the need to do something until after it is done.