If you're just using the pre-compiled binaries, this Go patch is baked in. If you're building the CockroachDB binary from source, and are just following our usual build steps using Bazel, you'll get this stuff as is. There's no need to compile a custom Go first.
Indeed I was referring to yugabyte, apologies for the clumsy phrasing, I havent used crdb but I guess it is a postgres frontend layered on a KV store instead of a document store?
CockroachDB (aka CRDB) is completely custom and compatible with Postgres wire/datatype protocols, which operates directly on its own key/value store called Pebble (but originally was also RocksDB): https://www.cockroachlabs.com/blog/distributed-sql-key-value...
Both systems are foundationally the same SQL-on-KV but implement it very differently.
(crdb eng here) I'll shamelessly call out that distributed backup/restore, which was previously in our enterprise offering, was moved into the free one. Internally a large part of that decisions was driven by the "suggestions" made here on HN, so keep 'em coming.
I've been following cockroachdb for a long time, and it irked me that distributed backup was something you had to pay for. Hat tip to the CRDB team for moving it into the open source product. It seems you listened to the criticism of folks on HN and took it to heart.
Why was it in the enterprise version to begin with?
Quote: “The first [of the CCL features] is a fully-distributed, incremental capability for quickly and consistently backing up and restoring large databases using configurable storage sinks (e.g. S3 or GCS). The same functionality, but non-distributed, will be available for free to all users.”
I can't speak to what exactly the thinking was at the time (I wasn't around yet) but as you mentioned, the community told us that the non-distributed functionality (DUMP) wasn't good enough for the scale people wanted to run at. Makes sense, so we made the change.
If I had to take a guess DUMP was performant enough at the time for most of our CockroachDB Core users and their scale, but adoption has picked up since then, as have data sizes.
Do you, like, work for Materlize? You're awful connected to many of the folks there and this is a pretty plant-like statement to make in the comments section for a piece by the company.
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data."
It's not, not at all. We've actually gone as far as replacing RocksDB with https://github.com/cockroachdb/pebble/ by default now (and it's written in Go).
What I mean is - and I get that these are somewhat different technologies - snowflake offers a more seemingly comprehensive platform for data by aggregating it and focusing the product on that aggregation for future use.
Compared to Cockroach DB which seems like a niche SQL replacement?
Congrats on the launch! If you're looking at CockroachDB (looking at some other comment on this thread), you should reach out to us if you haven't already. Your design here seems like the exact kind of thing we're hoping to push towards.
