P.S.
... 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:
https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...
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...
With that said, it'd be nice if you put that in yer FAQ.
That + foundation db pulled the carpet out from all their users at the time apple purchased them. Cannot trust that team / product again, it would be incredibly and blasphemously foolish. At least CDB likely won't pull any such stunt.
Disclaimer: I was personally affected by the FDB team making this choice back in 2015 when events unfolded. Still leaves a bitter taste.
Now it's an opensource project backed by Apple. And from what I can tell the team is massively different these days. I'm not sure why the obvious conclusion is "we can't trust them".
I've heard this narrative from people that got burned by fdb's purchase so I'll never use it again multiple times. It's largely confusing to me, as it doesn't feel connected to the current realities.
Noted that this is not quite discoverable. I'll push to get that fixed on our end. We'll also include a brief overview of our motivation for the change.
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.
The sysbench metrics seems like a much fairer comparison, and CockroachDB looks great in those metrics as well, so I don't really get why you are leading with a comparison that looks really sketchy at first glance.
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.
[1]: https://www.cockroachlabs.com/blog/how-we-built-a-vectorized...
Last I checked this was impossible.
Agree with the OP, no way of doing backups is kind of a dealbreaker even for hobby use :/
On my own laptop I’ve found it to be maybe 85% or so as quick as normal single mode Postgres. That said things aren’t great when the storage layer is doing consensus and replication and then the database is as well.
Yugabyte is a multi-model database built in C++, uses Raft + RocksDB as a distributed key/value store, and then implements a proprietary document-store model on top called DocsDB. This is exposed as a Redis API, Cassandra API, and now PostgreSQL RDBMS interface by using the actual Postgres code for the SQL layer. Much higher compatibility with Postgres with all data types, most advanced SQL, and even some extensions that work without problems. Not as advanced on the distributed side and uses more of a primary/replica setup.
Both are great options for a distributed scalable RDBMS with Postgres.
However, I think it's sad that their pricing is so opaque.
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.
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.
With AWS and Google Cloud (their main competitors), we know that prices won't be jacked-up.
———
An interesting example of this mistake is Mapbox.
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.
Then, 6 months later, Mapbox CEO posted this blog post:
https://blog.mapbox.com/new-pricing-46b7c26166e7
[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
Perhaps CockroachDB could unlock similar benefits by making their pricing/sales more open.
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?
In case you haven't seen them, for now, we have docs on some data placement patterns for multi-region deployments: https://www.cockroachlabs.com/docs/stable/topology-patterns..... We believe the first and third are best for most cases. This tutorial also walks through the impact of using those patterns in a cluster spread across 3 regions of the US: https://www.cockroachlabs.com/docs/stable/demo-low-latency-m...
But we'll definitely continue working on better guidance here.
I don't think the your product documentation has to explain what Kubernetes is or its terminologies[1].
The worst part is that it does not tell the cluster admins what need to be setup in the Kubernetes cluster at all, instead, it wraps a bunch of `kubectl` commands in a Python script and says "just download the script and run it"[2]. I know a simple `python setup.py` command is easier for novice to just try out. But it could really gives seasoned Kubernetes admins some headache...Our clusters enforce GitOps and nothing can bypass pull requests. Running some random `kubectl` commands is simply impossible. I ended up spending my day reading and translating the script into Kubernetes object definitions by hand and I didn't enjoy it...
1. https://www.cockroachlabs.com/docs/stable/orchestrate-cockro... 2. https://github.com/cockroachdb/cockroach/blob/master/cloud/k...
Other than that, I really wish I could use CockroachDB at "$COMPANY". Our architects, unfortunately, deem it “too new” and “unproven”. Bah.
“““ We wanted to find a solution that would minimize frustration (and time-consuming meetings) internally, while setting the correct expectations with users around quality and stability. ”””
Honestly, this doesn't explain much. If anything, hearing “FooDB 19.1” makes me think of stuff like React 16 or Chrome 69. That is, of “hip dudes” who “live fast and bump major versions”. On the other hands, hearing “FooDB 2.16” would make me think “Yep, this thing seems stable as Perl or Linux”. The meetings point also doesn't explain anything. Go simply does a minor version bump every six months. Why couldn't Cockroach Labs just do that?
Oh well, who cares, really, as long as the product is great.
<!-- End Google Tag Manager -->
Additionally, paste this code immediately after the opening <body> tag:
<!-- Google Tag Manager (noscript) -->
This is why we need XHTML.
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.
Glad to hear you signed up for the beta. We've been letting people off in batches and hope you can use CockroachCloud for your apps! If you have any feedback on the beta product, do let us know!