Live data from Hacker News

CockroachDB 19.2

cockroachlabs.com

11–20 of 63 posts

Re: CockroachDB 19.2

#11
post #9

Waiting for the comments about the name. On a more serious note, looking forward to trying this new release out. I found previous versions really straightforward to get up and running with on Kubernetes but performance was always lacklustre.

Performance in what sense? Searching online for benchmarks gives some impressive numbers, specifically this: https://www.cockroachlabs.com/blog/cockroachdb-2dot1-perform....

Others have commented about how the language that CockroachDB was written in causes performance issues due to Go using a GC. Can't say that this is the main reason for sure, but I guess it could be a possibility.

Re: CockroachDB 19.2

#12
post #9

Waiting for the comments about the name. On a more serious note, looking forward to trying this new release out. I found previous versions really straightforward to get up and running with on Kubernetes but performance was always lacklustre.

You can find our more recent performance numbers on https://www.cockroachlabs.com/docs/v19.2/performance.html

Re: CockroachDB 19.2

#13
post #10

Earlier quoted context omitted.

Probably has to do with their decision to name it after the cockroach. I mean, if they had called it MaggotDB or BotFlyDB or TapewormDB, people might find it unappealing.

Those aren't nearly as resilient though. Now, if you made a version of sqlite that replicated itself inside your program then you could use botfly ...

The successor will have to be named TardigradeDB.

Re: CockroachDB 19.2

#14
post #9

Waiting for the comments about the name. On a more serious note, looking forward to trying this new release out. I found previous versions really straightforward to get up and running with on Kubernetes but performance was always lacklustre.

I respect the name at this point. It won't go away - just like a real Cockroach and a distributed fault tolerant database system.

Re: CockroachDB 19.2

#15
Some comments I have regarding the documentation. It seems like there is a lot describing how to set up a cluster and how to do various SQL operations that most people probably know how to do.

I think the information that should be presented much more clearly are:

1.) How do we have to partition our data/what restrictions are in place? Basically, what considerations are necessary when designing the data model due to the constraints of the technology?

2.) What functionality that we expect from RDBMS do we give up when working across partitions? Can foreign keys exist across partitions? Can joins work? Inner/Right joins?

Re: CockroachDB 19.2

#17
Excuse me if that has been discussed numerous times, but I distinctly remember CockroachDB 2.0 coming out, and it being a big deal. Where are releases 3.0 to 19.0? Was the versioning scheme changed? How? Why?

Other than that, I really wish I could use CockroachDB at "$COMPANY". Our architects, unfortunately, deem it “too new” and “unproven”. Bah.

Re: CockroachDB 19.2

#19
post #17

Excuse me if that has been discussed numerous times, but I distinctly remember CockroachDB 2.0 coming out, and it being a big deal. Where are releases 3.0 to 19.0? Was the versioning scheme changed? How? Why? Other than that, I really wish I could use CockroachDB at "$COMPANY". Our architects, unfortunately, deem it “too new” and “unproven”. Bah.

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/

Re: CockroachDB 19.2

#20
post #17

Excuse me if that has been discussed numerous times, but I distinctly remember CockroachDB 2.0 coming out, and it being a big deal. Where are releases 3.0 to 19.0? Was the versioning scheme changed? How? Why? Other than that, I really wish I could use CockroachDB at "$COMPANY". Our architects, unfortunately, deem it “too new” and “unproven”. Bah.

[deleted]
Post reply on HN