a-robinson

"Basic" (i.e. full) backups have been included in the OSS version since its November 2020 release (20.2): https://www.cockroachlabs.com/blog/backup-restore/

They are still pretty limited compared to what's in the enterprise version, but it's not right to say basic backups are closed source and have never been there.

> My current database is in a private subnet, it would be unfortunate to have to open it up to the world to take advantage of this.

Agreed, this is a big current limitation. As mentioned in the blog post, though, we'll be adding support for connecting into private networks via our other networking products (Cloudflare Tunnel and Magic WAN).

Misleading title -- it isn't claiming that there are any newsletters generating $22M a year individually. It's just saying that the top 27 (why 27?) newsletters in aggregate make at least that much.

Yes, exactly!

WebSockets are actually already supported! See the "Can Durable Objects serve WebSockets?" section from the closed beta announcement last fall: https://blog.cloudflare.com/introducing-workers-durable-obje...

Storage is replicated across a handful of nearby sites. It does add some latency to writes, but that's preferable to Objects being offline or lost in the case of hardware or network failures.

There's no Jepsen testing in the works at the moment, but we'll see if it makes sense in the future.

It means that you'd use a different ID to access each document. Each document's Durable Object would run the same code as part of the same namespace of Durable Objects, but have their own in-memory and durable state. Check out the docs for a bit more context: https://developers.cloudflare.com/workers/learning/using-dur...

I'm not a tax lawyer, but 20% is the long-term capital gains rate for earnings greater than $400k or so - https://www.nerdwallet.com/blog/taxes/capital-gains-tax-rate...

That page also calls out a "net investment income tax" that sounds like it would add an additional 3.8% on such large capital gains.

They switched to calendar-based versioning earlier this year with the 19.1 release, for reasons explained in this blog post: https://www.cockroachlabs.com/blog/calendar-versioning/

With how often I've seen spaced repetition mentioned online recently, I'm starting to assume there's a grand conspiracy that's trying to use spaced repetition to trick me into remembering about spaced repetition.

In this case it actually makes sense because it's not easy to find a non-paywalled version of the paper.

Amazon - https://aws.amazon.com/rds/aurora/details/postgresql-details...

To add on to that last point, you don't need to pick in advance which region or regions your code will run in. You push your code once, and it will run in whichever edge locations receive requests, potentially all 165+ locations if you have users sufficiently spread around the world.

Yeah, it appeared to just be general resource contention from having to share the machine -- CPU interrupts, less memory available, etc.

I'll note, though, that the 5% number is when using host networking for both Cockroach and the client load generator. Using GKE's default cluster networking through the Docker bridge is closer to 15% worse than running directly on equivalent non-Kubernetes VMs.

WAN-optimized consensus protocols like Mencius and Egalitarian Paxos indeed are better for writes because any node can commit a write in one round trip, but they don't allow for reads with zero round trips. Every read must go through the consensus machinery in order to ensure consistency, whereas in CockroachDB the leaseholder can serve reads without needing to consult other nodes.

Yes: https://github.com/cockroachdb/cockroach

The parent poster was referring to CockroachDB as CRDB.

It's actually even in 1.0.0! We just haven't written about it previously.

The doc you found is the best resource. If you want even more detail, you can check out the original RFC: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

It helps with both, but is more dramatic for reads.

Reads go from 1 RTT to 0 RTTs, while writes go from 2 RTTs to 1 RTT. For example, consider a cluster in which the nodes are 200ms RTT away from each other.

* A read will take 200ms if the leaseholder isn't in the local datacenter vs single-digit milliseconds if it is local.

* A write will take 400ms if the leaseholder isn't in the local datacenter vs 200 milliseconds if it is local.

The write takes 400ms because it takes 100ms to get from the local datacenter to leaseholder, 200ms to reach consensus (the leaseholder needs to send a request to and get a response from one of the followers), and another 100ms for the response from the leaseholder to get back to the local datacenter where the request originated.

Why didn't they just set up a Patreon page for themselves?

For single-key operations only, but that is still much better than the average system he's looked at.

The Dynamo paper is from 2007... How much has Amazon published about their internal workings since then?

CockroachDB reads are strongly consistent, not eventually consistent. You don't have to wait at all.

Yes, it works. Your latency will just be correspondingly higher (due to the speed of light). We are constantly testing a cross-region (i.e. US-East and US-West) cluster and have periodically run tests on cross-continent clusters (US to Asia-Pacific).

In these cases you can help the cluster out by following some of the advice on the "Recommended Production Settings" page (https://www.cockroachlabs.com/docs/recommended-production-se...) around specifying which `--locality` each node is in.

Yeah, I'm really looking forward to a true local storage option. I'd recommend watching https://github.com/kubernetes/kubernetes/issues/7562 and https://github.com/kubernetes/kubernetes/pull/30044 if you want to keep up with how things develop.

I believe krenoten is referring to something along the lines of https://github.com/kubernetes/kubernetes/issues/7562

Sorry about that! They should all be working now.

It's not clearly advertised on their landing page, but it looks like the lifetime registration fee is being waived for a limited time, so if you're interested at all you should consider signing up now.

"Metrics from Kubernetes 1.2" is discussing the latency of requests to the Kubernetes API (for managing what's in the cluster).

The latency referred to in the demo is the latency of requests from the loadbots to the nginx containers running in the cluster.