Yes, the popular fork is called Postgres. You can find many vendors who will let you run it on one node cheaply. It’s also free to self-host.

In what way is postgres similar to cockroachdb? Except for being a database. Going by that standard you might as well say that Access is an alternative to postgres. Which it technically is but...

Cockroach marketed themselves as largely Postgres-compatible, so I guess there's that.

I guess that's true, I didn't think about that. But i think that you'd probably not be using cockroachdb if you were fine with what postgres offers. Cockroach might be compatible, but it really isn't "comparable" in terms of use cases and deployment imo. I might be totally wrong though, I have not been following it and Postgres closely since some time around 2021?

It's useful to use a Postgres-compatible syntax. The point of Cockroach was always to compete with globe-spanning DBs like Spanner, not with (possibly) sharded PG.

Citus gets close for many usecases but the HA story sucks: https://github.com/citusdata/citus/issues/7602

PG is nowhere close of What Cockroach does and probably never will.

CockroachDB was already under the BSL. It's interesting that they're further restricting it... Perhaps the BSL isn't the panacea folks are making it out to be.

it hasn't been open-source since 02019 according to https://en.wikipedia.org/wiki/CockroachDB#History so if there are popular forks they'd have to be five years old

BSL code automatically converts to open source at a specified date. So probably several releases since then are now as open source as anything else in the world. And if not, then they will be soon - BSL allows a maximum 5 year delay.

that may be (i haven't read the license) but i'm not persuaded it's relevant

if nobody forked it five years ago, they probably aren't going to fork it now

if somebody did fork it five years ago, they probably aren't going to try to merge in new source code drops as they convert to open source

Then why do you care? If nobody is going to fork it anyway, what’s the benefit of being open source from the beginning?

i don't care that much because i don't use it, and evidently not much of anybody else does either, or there would have been a popular fork. i'm just saying that this is probably not a good time to expect one to pop up

> 02019

Why not 002019? 6 digits. That would be valid a lot longer.

i wholeheartedly support your choice to henceforth format your years with six digits

I'm waiting for python support first. Not sure what the eta is or why it's taking so long. Every day we get closer to the eventual deadline.

> Extended date representations are not currently supported (±YYYYYY-MM-DD).

https://docs.python.org/3/library/datetime.html#datetime.dat...

> MAXYEAR is 9999.

https://docs.python.org/3/library/datetime.html#datetime.MAX...

I'm also waiting for longnow.org to start using long dates behind the scenes, like image urls, html metadata, http headers, etc. They need to eat their own dog food as far as software goes.

    <link rel="icon" href="https://static.longnow.org/2022/06/favicon.png" type="image/png">
    <meta property="og:image" content="https://static.longnow.org/2021/10/header-talks.jpg">
    <meta property="article:modified_time" content="2024-06-11T17:21:23.000Z">

This is really painful, I don't want this pattern of data collection being common, Telemetry included.