Hi all,

We are excited to announce the launch of a beta version of our new SQLite Cloud service. This service allows you to easily and securely share your SQLite databases in the cloud, eliminating the need for local storage or expensive server setups.

With our SQLite Cloud service, you can access your databases from anywhere, anytime, and on any device with internet access. Our platform is built on top of the latest security technologies, ensuring your data is always safe and protected.

Our easy-to-use interface lets you create and manage SQLite databases quickly and easily without coding or technical expertise. You can also share your databases and collaborate in real-time, making it the perfect solution for businesses, developers, and individuals.

Sign up today and start enjoying the benefits of our fast, secure, and reliable SQLite Cloud service (while in beta, the service will be completely free).

More on: https://sqlitecloud.io

For any information please contact us from: https://www.sqlitecloud.io/support

Thanks, Marco Bambini SQLite Cloud, Inc.

For those who care about this sort of thing …

This is an example of SQLite over Raft, with Raft ensuring database promulgation and consistency (ACID). So you can have multiple copies of your database around the world, local to each of your locations, or take backups without interrupting production.

https://raft.github.io

As you'd expect, you need an account. There's a web-facing dashboard so an admin can control accounts and databases.

With a one-line MACRO change you can recompile your program switching using a local database and a Cloud one, which allows for easy development. Documentation, but not full source code, is on github:

https://github.com/sqlitecloud

The website is unfinished, but that just reflects the beta status of the project, as announced in the pst.

Isn't RAFT one of those "usually inconsistent" things that the kiddies are enamoured with?

My mistake, RAFT is a general distributed consensus algorithm, which if implemented properly means "always consistent". The "usually inconsistent" (called "eventually consistent" by the kiddies) is an entirely different kettle of fish derived from the "no authoritative master" principle of mayhaps design.

We guarantee strong consistency across all the cluster nodes. I'll explain all the technical details in a blog post.

I just published a blog post with more technical information: https://blog.sqlitecloud.io/strong-consistency-with-raft-and-sqlite

Good explanation. I was in process control systems before retirement which will explain why I refer to what the kiddies call "eventually consistent" as "usually inconsistent" which generally equates to "useless".

The very software hosting this discussion is an AP-mode system, thus "eventually consistent."

Care to walk that charge of "useless" back a bit?

No. I would not run my refinery on it though, no matter how you feel.

No. I would not run my refinery on it though, no matter how you feel.

Huh. Ok, Keith. I will bite, and ask: Why wouldn't you? It's all over the world in billions of electrical devices. And they are working ok. So, since I am a big fan of your work, I would like to see a few reasons why, if you don't mind. Thanks.

Fossil is on billions of electrical devices? I don't think so.

Ooooohhh, now I get it. Ok, thanks. Wrong software.

I am not an expert, but I use Fossil at work, and I love it. I also use the ticketing system, and when people say what are you working on, I send them a link with my opened tickets. They love it, as I. But, that is the depth of my insight.

It is not "eventually consistent" in the presence of partitioning.

You're misapplying the CAP theorem. AP means it is always Available in the presence of Partitioning, specifically sacrificing Consistency. Thus fossil set autosync off, or the ability to say "no" to the sync failure prompt when it fails to sync due to a network error. When the partition is fixed, then it can become consistent, requiring some number of syncs depending on which repos cloned from which others.

Thus "eventual."

I have multiple times had to rebuild the repository

Simply needing to rebuild isn't a sign of problems. One of the things it does is vacuum the underlying SQLite DB, for instance. It also rebuilds delta information in the most efficient manner, and other helpful maintenance tasks.

it got "inconsistent" and unable to "fix itself" without "manual intervention";

It would have been good to have that repo so we could see it and debug the problem.

I've been using Fossil longer than you, and I've never seen it do that sort of thing.

delete the fubar clone and start anew.

I can only recall ever having one repo DB so badly messed up it couldn't be recovered, and that could easily have been due to the normal ways any SQLite DB can be messed up.

The way you write it, you'd think this happened frequently. In my experience, it's exceedingly rare, and I have yet to ascribe the source of the problem to Fossil itself.

Yes, it is rare. And yes, in order to fix it you have to delete the whole repo and re-clone it. I think the root of the problem is that it is possible to "unmerge" a commit on a branch in the "master" where the commit has already been replicated and then is attempted to be "reverted" on a later sync after it has already been propagated.

I have asked several times when this happened how to fix it, but no one knows how other than to delete the entire repository and start afresh.

There are many-many systems, e.g. e-mail and NNTP, git and even fossil itself, where trying to make in "consistent" will be not only just waste of effort, but also severely restrict their usability if succeed. And as decentralized systems are harder then centralized swelter, this is the opposite of kiddies, who lost ability even to federate and doing just centralized web-sites nowadays.

Thanks Simon,

SDK(s) source codes and the SQLite bridge source code will be released next week.

Repo with SDK(s) source code is now public: https://github.com/sqlitecloud/sdk

Podcast about SQLite with Marco. I have not yet listened to it:
Why SQLite is Taking Over with Brian Holt & Marco Bambini

What does this mean on the sqlitecloud.io page:

Backed by the creator of SQLite.

Does Richard approve of the implementation or something?

From the transcript, at 31.01 mark

We have a huge endorsement because Doctor. Rip, which is the original SQLite author, is one of our investor.