Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

Post reply on HN
Print view View original

251–260 of 366 posts

Re: CockroachDB 1.0

#251

Post by greenshackle2 »

jordanlewis wrote: post #231
daliwali wrote: post #185

Earlier quoted context omitted.

I double checked my codebase and it looks like it's just JSONB, which CockroachDB also doesn't support [0]. Sorry to bother about missing features, but there are really some things that prevent a smooth transition from Postgres. [0] https://github.com/cockroachdb/cockroach/issues/2969

Yep, JSONB is on our roadmap as well, although it won't come before array column type support. Thanks for the feedback - I'd personally love to see migrations from PostgreSQL to CockroachDB become seamless for more complex use cases as we continue development.

It occurred to me to migrate Odoo ERP to CockroachDB, scaling up the DB is one of our biggest challenges with some of our clients.

However Odoo leans heavily on Postgres, migration would be a lot of work I imagine. The first snag I've hit with CockroachDB is the lack of 'CREATE SEQUENCE'.

Plus, Odoo uses REPEATABLE READ + a hand-rolled system of locks for consistency, I'm not sure how that would play out with CockroachDB. In my experience some of the performance issues come more from long lived locks in the app than from sheer DB performance.

Re: CockroachDB 1.0

#252

Post by rubyn00bie »

eridius wrote: post #232
rubyn00bie wrote: post #224

Earlier quoted context omitted.

I disagree that it's tough to judge but that's because they've raised a considerable amount of capital ($53 million over three rounds): https://www.crunchbase.com/organization/cockroach-labs#/enti...

The end goal of a company is not to raise venture funding. So you cannot use "they raised capital" as proof that their name isn't a problem. Their name absolutely will hurt their adoption. Maybe the product is good enough that they'll still be successful, but if so, you would expect them to be even more successful if they didn't have such an off-putting name.

Did I say it was the end goal? It's merely a metric for a young company. What it means is that enough people have decided that there is a future that current revenue, growth, and expectations are being met or substantial. Raising $53 million dollars isn't easy. So I can say capital raised is a metric on which to base a judgement.

Your statement that it "absolutely will hurt adoption" is unqualified and nothing but opinion. And what exactly is "more successful?"

The handful of people who won't try this because of the name won't matter to their bottom line. If it's good enough then for even a large majority of those they'll end up using it anyway.

Re: CockroachDB 1.0

#253

Post by deno »

deno wrote: post #54
crudbug wrote: post #43

Earlier quoted context omitted.

Yeah, I suggested "RoachDB" a while back. Which sounds more pleasant. There was a github issue for this as well.

Was about to suggest that before I saw your comment. It’s like that PostgreSQL vs Postgres naming fiasco all over again. It’s not even the association, which I actually think is great, the name is simply a mouthful. RoachDB rolls off the tongue just so much better.

On second thought I’m not sure. Everyone will call it RoachDB for short anyway, but the full name has more impact. It shocks, which is a good thing. I was so focused on aesthetics that I didn’t even consider strategy.

They can always spin off “RoachDB” as an enterprise option, if they have any problems with selling it due to name.

Re: CockroachDB 1.0

#254

Post by stock_toaster »

phlakaton wrote: post #242
stock_toaster wrote: post #217

Earlier quoted context omitted.

> ...but that is the definition of bike-shedding (aka law of triviality) > A committee won't vote for my nuclear plant because the bike shed is red. > The bike shed's color has concrete effects on adoption. Not exactly. > Parkinson observed that a committee whose job is to approve plans for a > nuclear power plant may spend the majority of its time on relatively > unimportant but easy-to-grasp issues, such as what ma…

Please tell me we're not having a bikeshedding discussion on the meaning of bikeshedding. :-)

We probably are. ;)

It's so meta it hurts.

Re: CockroachDB 1.0

#255

Post by fulafel »

Svenskunganka wrote: post #114

Pardon the nature of my question, but I'm really interested in what your experience has been so far building a database with Go? Has its runtime (the GC for example) posed any issues for you so far? Looking at other RDBMS's, languages with manual memory management like C or C++ seems to be the go-to choice, so what were the reasons you chose Go? I'm quite frankly amazed that Go's runtime is able to support a database…

What would be the risk with GC?

Re: CockroachDB 1.0

#256

Post by phlakaton »

therealmarv wrote: post #82

Does this work theoretically interplanetary (just asking because for science) ?

More practically, I note this from Cockroach's document on "Deploy > Recommended Production Settings":

"When replicating across datacenters, it’s recommended to use datacenters on a single continent to ensure performance (inter-continent scenarios will improve in performance soon). Also, to ensure even replication across datacenters, it’s recommended to specify which datacenter each node is in using the --locality flag. If some of your datacenters are much farther apart than others, specifying multiple levels of locality (such as country and region) is recommended."

In short, IIUC, even _planetary_ deployment doesn't come for free (yet). Perhaps I'm just not well-enough versed yet in how people deal with globally-distributed databases, but I'd love to see the docs dig into this a bit more: practical limits of cluster deployment, recommended strategies and tools (if any) to replicate data between clusters, etc.

Re: CockroachDB 1.0

#257

Post by zzzcpan »

nickpsecurity wrote: post #227
benesch wrote: post #53

Earlier quoted context omitted.

[Cockroach Labs engineer here.] Yes, if very low-latency (i.e., P99 latency sub-5ms) reads and writes are critical to your application, CockroachDB should not be your first choice. That said, one of the primary motivations for CockroachDB is that most existing systems don't handle eventual consistency well. In our experience, most developers will eventually write code that assumes a consistent database, either accide…

I support the default on consistence the way you posed it. Main reason is safe-by-default construction has proven more effective for average programmer over decades. The other approach caused many disasters.

Meh, this is just pr, nothing is safe-by-default. It's not actually true that people eventually assume strong consistency, because eventual consistency forces certain stricter way of thinking about the state and time, kind of functional, you just can't escape it. It's strong consistency that lets you get sloppy, while making you forget how not simple it is. It only exists inside the system and if you have clients from the outside of the system, like web browsers, you don't have two phase commit protocol on a button click there, so you have to resort to that same functional way of thinking to at least try not to confuse anyone on retry, but it's clearly not the case in the wild. It's just too complex.

I don't think anyone goes back from eventual consistency. It's more appropriate for this asynchronous world, easier and more reliable.

Re: CockroachDB 1.0

#258

Post by lovich »

sandstrom wrote: post #221
SilasX wrote: post #168

Earlier quoted context omitted.

It's not bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Most people -- i.e. in procurement, management, finance, and others you need to appeal to -- don't want anything to do with cockroaches. The idea disgusts them at a gut level, not something you can talk away. HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame. As I say every…

Mongo (similar to 'mongolism', another term for Down's syndrome) has done just fine, despite (or thanks to!) their name. There was similar criticism about their name in the early days, but it has waned as mongo has grown. This will too.

Wasn't mongo slang for humongous? Like Mongo from Blazing Saddles?

Re: CockroachDB 1.0

#259

Post by fs111 »

disconnected wrote: post #225
rgacote wrote: post #177

Earlier quoted context omitted.

Much better to name it something like Oracle, after a mythical seer who gives cryptic, self-contradictory answers open to wild interpretation.

Well, since this discussion has already gone down the tubes, we might as well spend some productive time making fun of other DB names: - SQLite: SQL database with no sugar. Less calories! - MySQL: A selfish database. - IMB DB2: Released in 1983, but never got promoted to DB3. Probably abandoned software? - Postgresql: Gesundheit! - CouchDB: A database for lazy people. Part of the NOSQL family, the Zen database family…

> - MySQL: A selfish database.

MySQL is named after the founder's daughter "My". The fork is named after his other daughter "Maria": https://en.wikipedia.org/wiki/Michael_Widenius#Personal_life

Re: CockroachDB 1.0

#260

Post by [deleted] »

andkon wrote: post #205
newsat13 wrote: post #160

Very disappointed with HN turning into a 4chan/reddit style trolling board about the name. Guys, we get it that you don't like the name. Can we please stop bike shedding and move on? The people at cockroachdb have obviously seen all your messages but decided it's worth keeping the name. What more is there to talk about? Why not talk about the relative technical merits of this DB?

So I do product marketing for a living, and have launched a whole wack of things with good and bad and boring names. The fact that CockroachDB is consistently on top of HN with each thing they do is pretty strong evidence that they're doing just fine with the name they have, and probably doing even better than if they had a milquetoast tech startup-esque name. Also, they know what their sales cycles look like. They h…

[deleted]
Post reply on HN