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.<p>I think the information that should be presented much more clearly are:<p>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?<p>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?
Is the primary advantage of CockroachDB over FoundationDB primarily in supporting SQL out of the box? The multi-region support seems pretty banger at first glance.<p>P.S.<p>... and I had a tirade here about the licensing information being largely absent on their FAQ or product pages, but I did find this after a google before posting:<p><a href="https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/" rel="nofollow">https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...</a><p>which... from what I can tell at my cursory inspection, seems okay to me. I'd be pretty pissed too assuming a giant SaaS company came by, forked their product, and then resold it with improvements they didn't upstream. Mostly, because it's just fucking rude. One could have a good business relationship with another company with both prospering, but instead you take the short-n-shitty road for no reason...<p>With that said, it'd be nice if you put that in yer FAQ.
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?<p>Other than that, I <i>really</i> wish I could use CockroachDB at "$COMPANY".
Our architects, unfortunately, deem it “too new” and “unproven”. Bah.
Glad to see Cockroach Cloud, I signed up for the beta.<p>I'm only really interested in an elastic, managed program with transparent pricing. As a contractor with a fair amount of exposure to various startups around the bay, I find these to be relatively ubiquitous criteria.
Waiting for the comments about the name.<p>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.
Heh, they didn't seem to test their University website[1] before
publising it. There is a gaping:<p><pre><code> <!-- End Google Tag Manager -->
Additionally, paste this code immediately after the opening <body> tag:
<!-- Google Tag Manager (noscript) -->
</code></pre>
In the source code. That “<body>” isn't escaped either, which makes the
whole thing borked-up.<p>This is why we need XHTML.<p>[1] <a href="https://university.cockroachlabs.com/catalog" rel="nofollow">https://university.cockroachlabs.com/catalog</a>
Awesome to see a new release! We've followed Cockroach for a while, would be a good fit four our workload.<p>However, I think it's sad that their pricing is so opaque.<p>Even after a few emails back and forth with their sales people it still feels fairly arbitrary, and since it's not transparent we don't know if they're just making numbers up based on what they think we're willing to pay.<p>I find this sales-tactic off-putting. In theory it allow them to "not leave any money on the table", as they would probably frame it, but I'm curious how many deals they will lose simply because people don't want to be held hostage, or don't want to put up with the sales-hassle.<p>With AWS and Google Cloud (their main competitors), we know that prices won't be jacked-up.<p>———<p>An interesting example of this mistake is Mapbox.<p>They had a limited free tier, where most use-cases would be "talk to sales for pricing". We had a frustrating 2 months talking with their sales people, finally getting a reasonable deal. But we were very close to just ditching them for Google Maps (even though I liked Mapbox product better and was willing to pay more for it), just because the price negotiation and all the cheap sales-tactics was so time-consuming.<p>Then, 6 months later, Mapbox CEO posted this blog post:<p><a href="https://blog.mapbox.com/new-pricing-46b7c26166e7" rel="nofollow">https://blog.mapbox.com/new-pricing-46b7c26166e7</a><p><pre><code> [excerpt, from Mapbox CEO announcing pricing/sales rethink]
How we price our tools has a significant impact on how those tools get used
and what gets built with Mapbox. We were pricing some of our APIs wrong —
making things confusing and restrictive. Rolling out new pricing took
close to five months; informed by the stories of our builders
whose curiosity and insight gave us a lot of honest feedback.
Here’s what we were doing wrong:
- Unpredictable pricing at scale
- Development slowed by price modeling and negotiating volumes
- Unintuitive billing units
- Hard to compare measurement to our friends at Google
- Confusion around when commercial plans are needed
Our goal with this change is to reduce the friction to build with
our tools and to allow our team to help developers use maps and locations
more creatively. As we designed this new pricing, we kept our key
pricing principles in mind:
- Predictable and aligned with metrics our customers already measure
- Clearly defined discount tiers as businesses scale with no surprises
- Product usage measured in a way that’s clear to all involved
- Generous free tier to encourage building and make it easier to get started
</code></pre>
I experienced all those downsides, which almost pushed us to leave Mapbox, so very happy to see them reconsider (for their own sake).<p>Perhaps CockroachDB could unlock similar benefits by making their pricing/sales more open.
Somewhat related but why not have an object store like ceph but expose the guarantees of the data (cap or whatever) and just interact with objects? Bonus points for making the API pluggable.
Anyone use the cross data center clustering in the real world? Got a bunch of people considering this - a cluster spanning two data centers as the way to do transactional updates.