5 ms·

This was posted yesterday, complete with an inflammatory blog post. This fork has exactly zero new code, but they already managed to change the license and the

This was posted yesterday, complete with an inflammatory blog post. This fork has exactly zero new code, but they already managed to change the license and the code of conduct. Their plans include io_uring, Rust and WASM functions - the first two negate the "single-.c-and-.h multi-platform" paradigm that made SQLite what it is, the third thing seems like a feature very few people would care about. They also want to make SQLite distributed for some reason (uh, just use Postgres?)

hnov 4y ago
I think making sqlite distributed-capable is very interesting. Postgres isn't trivially distributed and is a full fledged database server that's not appropriate for scale to zero workloads, though others are working on that as well.
- maxbond 4y ago
  These do all sound like interesting ideas, but in our current Cambrian explosion of new databases (especially "X open-source SQL database you know and love, but distributed" forks) - you can fork SQLite and build that without being needlessly confrontational about it, or including the language about how they'll rejoin SQLite if their terms are met, which makes me feel like this is a fork about leverage as much as realizing a different vision for a database.
  - hnov 4y ago
    I imagine they love the sqlite codebase but are not ecstatic about having to maintain a fork and would like to have sqlite upstream their changes such that they don't have to import patches in perpetuity. This is a valid frustration that most commonly happens with OSS that's built by a corporation and thrown over the wall. I think in this case the dig at the end of the README is a way to be like "look at those religious cult members, closed off from accepting contributions" which is a cheap shot but all's fair in politics. A lot of companies build on top Linux, PG and others and are able to reach consensus with the community.
eatonphil 4y ago
Postgres is not a distributed database.
- Kwpolska 4y ago
  Sure, it isn’t. But most things do not really need a distributed database, just something usable from multiple locations, and Postgres solves that problem easily.
  - hnov 4y ago
    Most vehicles don't need rocket propulsion, yet you can't go to the moon in an FSO Polonez ;)
  - eatonphil 4y ago
    Just because you, personally, don't have a good reason for using a distributed database doesn't mean there aren't folks who do!
  - jitl 4y ago
    We thought that, built an app on Postgres, got huge, now we wish there was a distributed Postgres vendor on AWS. I’m grumpy Azure bought Citus. Maybe Aurora is trustworthy now? Like 3 years ago I’d still hear about it eating peoples data.
    - pritambaral 4y ago
      City's is fully open source now.
      - jitl 4y ago
        Sure - but it'd be nice to have it managed for us.
freedomben 4y ago
Are you talking about this blog post? https://glaubercosta-11125.medium.com/sqlite-qemu-all-over-again-aedad19c9a1c https://glaubercosta-11125.medium.com/sqlite-qemu-all-over-a... What part(s) is/are inflammatory? (I'm honestly asking because I don't see anything obvious and I wish to understand your perspective. I'm not trying to imply that there's nothing inflammatory there by using a question)
- chasil 4y ago
  I am guessing that "SQLite does not accept contributions" and "the industry is going in a new direction" are what most find objectionable. SQLite cannot accept random contributions. It's on A350 flight systems, where failure is not an option. The maintainers are able to uphold this quality, but random contributors are not. It appears that the true desire is log shipping (archived logs, transaction logs, etc.) - the ability to move transaction data between databases, perhaps in multimaster. The only way such functionality is getting into SQLite is if the project agrees to write it, likely for major funding. A fork implementing these features will be regarded with interest, but will not be accepted without substantial rework.
  - lonjil 4y ago
    > SQLite cannot accept random contributions. It's on A350 flight systems, where failure is not an option. The maintainers are able to uphold this quality, but random contributors are not. Do you think Airbus updates their copy of SQLite to the newest version constantly? Bugs make it into SQLite every release, and no released version of SQLite is known to be DO-178B compliant. Seems a lot more likely that it is as Dr Hipp said a few years ago [1], that some customers have qualified specific versions of SQLite in specific configurations for use in applications that require DO-178B compliance. He says that he thinks that those companies certified it to D or C level, which is non-critical stuff, like failure leading to passenger discomfort, e.g. they may be using SQLite in the in flight infotainment system.
  - threatofrain 4y ago
    How is that inflammatory? SQLite not accepting contributions is their own policy. Saying that the industry wants different features... is that inflammatory? This new fork wants contributors, so of course this is going to be a distinction of their project. Linux is used to run the world and there are failures as well as contributors.
rektide 4y ago
> Their plans include io_uring, Rust and WASM functions Awesome! That sounds kick ass! Turn up the perf some orders of magntude, use a safer kanguage with better tools, and make it usable safely from anywhere!? My heavens this db could go to all kinds of new places! > the first two negate the "single-.c-and-.h multi-platform" paradigm that made SQLite what it is, Seriously feels like c needs to grow past keeping everyone rubbing two sticks together to eek out cross-compatibility. We've been stuck at such a silly minima in c/c++ for so so long. Why is code not reusable? Also it helped, yes, but im not sure this simplicity is the defining "lite" thing of sqlite. Yes: that is damned lite to use/consume, abut it's just one characteristic mong other lite-nesses. It doesnt strike me as that essential. And if it's impedeing exoloration & growth & other uses... then heck yes a breakaway attempt should be formed. There's excellent material here, & limiting it to a tiny quaint shape & form, purely to help the ridiculous mess of build systems/package management (and especially their absences), seems like an extreme tradeoff. For sure there should be ventures to try to explore & go on, see what the other untapped values might be!! > the third thing seems like a feature very few people would care about. Well, i'd hope there's a lot of people who wouldnt think to care today that might tune in & turn on, if they had a lightweight db system that was easy to embed. I dont know how many billion devices have access to the web, but giving them the ability to use sqlite seems sharp & obvious! Yesterdays post on qemu painted a great picture of a similar case, of there being a ton of excellent materials here, but it being locked into a very conservative & narrow perspectuve of use. The breakout of qemu-kvm unlocking trapped potential, rewriting the world, seems apt. Progress ought have representation!

hnov 4y ago

I think making sqlite distributed-capable is very interesting. Postgres isn't trivially distributed and is a full fledged database server that's not appropriate for scale to zero workloads, though others are working on that as well.

maxbond 4y ago
These do all sound like interesting ideas, but in our current Cambrian explosion of new databases (especially "X open-source SQL database you know and love, but distributed" forks) - you can fork SQLite and build that without being needlessly confrontational about it, or including the language about how they'll rejoin SQLite if their terms are met, which makes me feel like this is a fork about leverage as much as realizing a different vision for a database.
- hnov 4y ago
  I imagine they love the sqlite codebase but are not ecstatic about having to maintain a fork and would like to have sqlite upstream their changes such that they don't have to import patches in perpetuity. This is a valid frustration that most commonly happens with OSS that's built by a corporation and thrown over the wall. I think in this case the dig at the end of the README is a way to be like "look at those religious cult members, closed off from accepting contributions" which is a cheap shot but all's fair in politics. A lot of companies build on top Linux, PG and others and are able to reach consensus with the community.

eatonphil 4y ago

Postgres is not a distributed database.

Kwpolska 4y ago
Sure, it isn’t. But most things do not really need a distributed database, just something usable from multiple locations, and Postgres solves that problem easily.
- hnov 4y ago
  Most vehicles don't need rocket propulsion, yet you can't go to the moon in an FSO Polonez ;)
- eatonphil 4y ago
  Just because you, personally, don't have a good reason for using a distributed database doesn't mean there aren't folks who do!
- jitl 4y ago
  We thought that, built an app on Postgres, got huge, now we wish there was a distributed Postgres vendor on AWS. I’m grumpy Azure bought Citus. Maybe Aurora is trustworthy now? Like 3 years ago I’d still hear about it eating peoples data.
  - pritambaral 4y ago
    City's is fully open source now.
    - jitl 4y ago
      Sure - but it'd be nice to have it managed for us.

freedomben 4y ago

Are you talking about this blog post? https://glaubercosta-11125.medium.com/sqlite-qemu-all-over-again-aedad19c9a1c https://glaubercosta-11125.medium.com/sqlite-qemu-all-over-a... What part(s) is/are inflammatory? (I'm honestly asking because I don't see anything obvious and I wish to understand your perspective. I'm not trying to imply that there's nothing inflammatory there by using a question)

chasil 4y ago
I am guessing that "SQLite does not accept contributions" and "the industry is going in a new direction" are what most find objectionable. SQLite cannot accept random contributions. It's on A350 flight systems, where failure is not an option. The maintainers are able to uphold this quality, but random contributors are not. It appears that the true desire is log shipping (archived logs, transaction logs, etc.) - the ability to move transaction data between databases, perhaps in multimaster. The only way such functionality is getting into SQLite is if the project agrees to write it, likely for major funding. A fork implementing these features will be regarded with interest, but will not be accepted without substantial rework.
- lonjil 4y ago
  > SQLite cannot accept random contributions. It's on A350 flight systems, where failure is not an option. The maintainers are able to uphold this quality, but random contributors are not. Do you think Airbus updates their copy of SQLite to the newest version constantly? Bugs make it into SQLite every release, and no released version of SQLite is known to be DO-178B compliant. Seems a lot more likely that it is as Dr Hipp said a few years ago [1], that some customers have qualified specific versions of SQLite in specific configurations for use in applications that require DO-178B compliance. He says that he thinks that those companies certified it to D or C level, which is non-critical stuff, like failure leading to passenger discomfort, e.g. they may be using SQLite in the in flight infotainment system.
- threatofrain 4y ago
  How is that inflammatory? SQLite not accepting contributions is their own policy. Saying that the industry wants different features... is that inflammatory? This new fork wants contributors, so of course this is going to be a distinction of their project. Linux is used to run the world and there are failures as well as contributors.

rektide 4y ago

> Their plans include io_uring, Rust and WASM functions Awesome! That sounds kick ass! Turn up the perf some orders of magntude, use a safer kanguage with better tools, and make it usable safely from anywhere!? My heavens this db could go to all kinds of new places! > the first two negate the "single-.c-and-.h multi-platform" paradigm that made SQLite what it is, Seriously feels like c needs to grow past keeping everyone rubbing two sticks together to eek out cross-compatibility. We've been stuck at such a silly minima in c/c++ for so so long. Why is code not reusable? Also it helped, yes, but im not sure this simplicity is the defining "lite" thing of sqlite. Yes: that is damned lite to use/consume, abut it's just one characteristic mong other lite-nesses. It doesnt strike me as that essential. And if it's impedeing exoloration & growth & other uses... then heck yes a breakaway attempt should be formed. There's excellent material here, & limiting it to a tiny quaint shape & form, purely to help the ridiculous mess of build systems/package management (and especially their absences), seems like an extreme tradeoff. For sure there should be ventures to try to explore & go on, see what the other untapped values might be!! > the third thing seems like a feature very few people would care about. Well, i'd hope there's a lot of people who wouldnt think to care today that might tune in & turn on, if they had a lightweight db system that was easy to embed. I dont know how many billion devices have access to the web, but giving them the ability to use sqlite seems sharp & obvious! Yesterdays post on qemu painted a great picture of a similar case, of there being a ton of excellent materials here, but it being locked into a very conservative & narrow perspectuve of use. The breakout of qemu-kvm unlocking trapped potential, rewriting the world, seems apt. Progress ought have representation!