cockroach VS rqlite

code in a given file is licensed under the BSL and ..." That is sucky.

[0] https://github.com/cockroachdb/cockroach?tab=License-1-ov-fi...

CockroachDB — Distributed SQL database built for cloud applications.

CockroachDB is a distributed SQL database designed for cloud applications. It provides strong consistency, horizontal scalability, and high availability.

Round rectangles can look not round enough on low-DPI displays, and the colors can also be wrong due to incorrect averaging in non-linear color space. Example: https://github.com/ClickHouse/ClickHouse/pull/33453#issuecom...

It is similar to how subtle gradients look striped and dirty on many websites if displayed with only 24-bit color: https://github.com/cockroachdb/cockroach/issues/91316

Restate is built as a sharded replicated state machine similar to how TiKV (https://tikv.org/), Kudu (https://kudu.apache.org/kudu.pdf) or CockroachDB (https://github.com/cockroachdb/cockroach) are designed. Instead of relying on a specific consensus implementation, we have decided to encapsulate this part into a virtual log (inspired by Delos https://www.usenix.org/system/files/osdi20-balakrishnan.pdf) since it makes it possible to tune the system more easily for different deployment scenarios (on-prem, cloud, cost-effective blob storage). Moreover, it allows for some other cool things like seamlessly moving from one log implementation to another. Apart from that the whole system design has been influenced by ideas from stream processing systems such as Apache Flink (https://flink.apache.org/), log storage systems such as LogDevice (https://logdevice.io/) and others.

We plan to publish a more detailed follow-up blog post where we explain why we developed a new stateful system, how we implemented it, and what the benefits are. Stay tuned!

CockroachDB is an open source distributed SQL database designed for scalability and resilience. While it offers SQL databases, CockroachDB is also compatible with PostgreSQL.

cockroachdb might be close: https://github.com/cockroachdb/cockroach

CockroachDB - SQL

For example, when you create a serverless postgres database with a platform like CockroachDB or Neon, you effectively get a connection string with a strong password. Anyone can connect to your database from anywhere so long as they have the right connection string. There are no security settings in these services to change this behavior.

> Yes you can on the android emulator. The biggest issue is compu arch in that case.

I can also download VirtualBox and run all Windows programs, that would mean that all Windows apps are Linux apps?

> Yes you can for the most part

You can't statically link glibc: https://github.com/cockroachdb/cockroach/issues/3392

glibc can break stuff: https://www.gamingonlinux.com/2022/08/valve-dev-understandab...

I had binaries break because the newer version if openssl was put under a slightly different name.

rqlite[1] could basically do this, if you use read-only nodes[2]. But it's not quite a drop-in replacement for SQLite at the write-side. But from point of view of a clients at the edge, they see a SQLite database being updated which they can directly read[3].

That said, it may not be practical to have hundreds of read-only nodes, but for moderate-size needs, should work fine..

Disclaimer: I'm the creator of rqlite.

[1] https://rqlite.io/

[2] https://rqlite.io/docs/clustering/read-only-nodes/

[3] https://rqlite.io/docs/guides/direct-access/

Not particularly. A C compiler is only needed for the SQLite source code.

I originally provided these musl-based builds so I could provide rqlite Docker images based on Alpine[1]. But now the Docker release process simply builds rqlite from the source during the image-creation process[2].

[1] https://hub.docker.com/_/alpine

[2] https://github.com/rqlite/rqlite/blob/master/Dockerfile

Not Jepsen tested but I'd like rqlite [0] would be in the running and meet the requirements.

0. https://rqlite.io/

I’ve been pondering doing something like this with SQLite. The primary db is local/embedded on the user’s machine and use something like https://github.com/rqlite/rqlite to sync on the backend.

It also means it would be fairly trivial to allow users/orgs to host their own “backend” as well.

SQLite is not competing with RDMBSes. SQLite is competing with fopen().

There are of course solutions which wrap this fopen() replacement in a network/cluster-aware tools, e.g. https://github.com/rqlite/rqlite - these are competing with postgres.

Seems like you could do the same with rqlite [1], since SQLite supports JSON.

[1]: https://rqlite.io