
Managed CockroachDB: Geo-Distributed Database as a Service - louis-paul
https://www.cockroachlabs.com/blog/launching-managed-cockroachdb/
======
thepumpkin1979
I've been using CRDB 2.0 for a toy project for a few weeks now, today I notice
2.1 was available so I started playing with some of their new features, I ran
a SQL query with correlated sub-queries and then the server crashed. It's the
first time I see a crash, so I rushed to the GitHub report to report the bug
and to my surprise a GitHub issue was already created for the crash[0], it
included the stack trace and an anonymized version of my SQL query that caused
the crash.

This really demonstrates they really care about the stability of their
product, one more reason to keep recommending CockroachDB.

[0]
[https://github.com/cockroachdb/cockroach/issues/32048](https://github.com/cockroachdb/cockroach/issues/32048)

~~~
beefsack
This is equal parts impressive and scary. It's awesome from a stability
perspective, but I'm not completely comfortable with "dial home" functionality
apparently being enabled by default in a database system.

~~~
rishav_sharan
If i remember it right, you can switch off the telemetry during installation

~~~
tyingq
Here's the details: [https://www.cockroachlabs.com/docs/stable/diagnostics-
report...](https://www.cockroachlabs.com/docs/stable/diagnostics-
reporting.html)

------
puzzle
So what's the price? For Spanner, which is perhaps their closest competitor,
it takes a few seconds to find at least the list price, before discounts and
such.

~~~
strict9
They sure don't make it easy to find on their site, though this post breaks
down some of it: [https://www.cockroachlabs.com/blog/aurora-price-vs-
cockroach...](https://www.cockroachlabs.com/blog/aurora-price-vs-cockroachdb/)

Cockroaches team also have their customers as a top level nav item now, though
Baidu is the only one I recognize:
[https://www.cockroachlabs.com/customers/](https://www.cockroachlabs.com/customers/)

~~~
_jezell_
They compared the free version pricing, not enterprise.

------
dsl
CockroachDB is looking more and more like a viable replacement for MySQL (now
that they have importing mysqldump in beta)

However key management in clusters is an absolute nightmare. They need to look
at Docker Swarm for how to build a usable "join" mechanism. Until then, the
majority of folks just use --insecure in production.

~~~
benesch
CockroachDB engineer here.

> However key management in clusters is an absolute nightmare. They need to
> look at Docker Swarm for how to build a usable "join" mechanism.

I'll contend that key management is one of the great unsolved problems in
software deployment.

I don't want to diminish the value of removing friction from the user
experience, but fundamentally there is not that much of a difference between
providing a token directly as a command line argument vs. providing a
certificate that lives on disk. I'm curious if your frustration is mostly from
the overhead of creating node certificates or if there's a deeper problem I'm
not seeing.

I should also mention: this is an area we're actively looking to improve in!
If you have time to write up a slightly more detailed proposal as a GitHub
issue, we'd be happy to entertain it.

~~~
jillesvangurp
I encounter way too much server software that seems written by people that are
insensitive to how modern deployments work.

Any instructions that involve "just login here, just run X, just fiddle with
that file over there", "just chant these incantations and perform our ritual
startup dance",etc are kind of broken. The more convoluted those instructions
get, the harder and more error prone it gets to automate the deployment in a
sane way. Manually messing with files on a filesystem happens on development
machines and laptops, never on production servers (unless you are dealing with
amateurs). And even there I would argue running docker is the preferred way
these days.

For me software comes in two forms these days. If it is stateful, I might not
run it in docker and I'll be building an AMI using packer and ansible. If it
is not, it is a docker image. In both cases I build one image or container (on
a build server) for one thing that gets booted many times on many servers in
the context of some deployment template. All of my configuration management
happens at image build time (packer or docker). After that no modifications
should be needed to their file systems and they should be read only for all
practical purposes. Any data goes into separate volumes.

At boot time you inject all relevant configuration via environment variables.
Ideally that is the same for all nodes of a type with no variation. Ideally
the software understands that environment variables are (by far) the preferred
mechanism to take configuration. Surprisingly few packages seem to get this
right and assume some grey beard is going to ssh into a server and be all over
their vintage nineteen seventies configuration files with extra weird syntax
in some completely non standard location. It's been decades since software
deployment actually worked that way. These days those files get templated,
written once and never modified again. The template cruft gets driven from a
script and that script is driven by environment variables. The more of that
cruft is needed, the harder it gets to deploy stuff.

So, insisting on per node provisioning of certificates to some location in a
filesystem kind of really sucks. I can totally see devops people disabling
that instead and relying on firewalls, security groups and network security
instead.

~~~
ants_a
Huh? A modern infrastructure setup should have PKI in place to issue
certificates to nodes. You are making it sound like SSL has no place in the
modern world.

~~~
jillesvangurp
Not making that point at all. Just making the point that related certificates
and keys need to be looked up at run time from some secure place rather than
be provisioned onto a file system at build time or via some hard to automate
sysadmin ritualistic dance on the command line post startup. If in amazon, the
secure parameter store is a good place for storing secrets. They also
provision nice EC 2 credentials to hosts allowing you to access resources
securely without having to rely on silly ssh keys baked into images or
passwords passed around insecurely. And of course they allow you to centrally
manage ssl certificates as well and manage provisioning those to things like
load balancers. Kubernetes has nice infrastructure for this as well.

The point is that this stuff should never be baked into docker or ec2 images
and having software expecting to find these things in some file on the
filesystem actively makes it harder to configure it in a sane way.

I've seen quite a few docker images that require me to mount a volume with
certificate files to work at all. The only way to beat some sense into that is
to customize the Docker file and template these files (e.g. dockerize is great
for this). Sane deployment automation seems to be an afterthought with many
developers.

Since you brought up SSL, a nice innovation a few years ago was
[https://letsencrypt.org/](https://letsencrypt.org/) which uses short lived
certificates that need to be renewed regularly. That sounds like a good
practice to do anywhere you use any kind of ssl connections. That would
require automation to refresh those certificates of course. Not just once on
startup but also before they expire. However, if the software reads keys only
once at startup from a file, part of that scripting is also becomes
orchestrating a restart; which I imagine can get a bit hairy in the case of a
clustered database product.

------
elvinyung
How is Cloud Spanner adoption nowadays? I seem to be hearing lately that more
and more teams are looking seriously into adopting it.

~~~
tyingq
They just added SQL DML (insert/update/delete) a couple of weeks ago. Adoption
will probably head up now.
[https://cloud.google.com/blog/products/databases/develop-
and...](https://cloud.google.com/blog/products/databases/develop-and-deploy-
apps-more-easily-with-cloud-spanner-and-cloud-bigtable-updates)

Edited to note "SQL DML"...

~~~
romed
To clarify, you could always do these things via the native RPC interface.
They added these things to the SQL interface.

------
rb808
I'm never sure what is better - a service that is 99% reliable and you're used
to failing over to a backup system because it happens a few times a year. Or a
system that is 99.99% reliable and you're ____ed when it goes down.

Is there a name for that dilemma and a preferred option?

I like the idea of super reilable services, but I'm also comforted by old
fashioned databases I know, and have dealt with lots of live problems.

~~~
qaq
1st option is better the 99.99 generally holds only if it is managed by
someone with very deep knowledge of the system and in case of CockroachDB it's
pretty much the core team.

------
beefsack
I asked previously when a CockroachDB post was on here, but didn't really get
an answer to it.

Is anyone running this in prod at a significant scale and able to comment on
reliability and performance?

I absolutely love CockroachDB in my toy projects, but am not yet feeling
comfortable to commit to using it in prod.

~~~
anaganisk
From what i can see from customers page: Heroic labs and baidu

------
notacoward
Congrats to the Cockroach crew. CockroachDB is a very interesting project, and
this will make its functionality available to a wider audience.

------
tyingq
_" available at launch on both AWS and GCP"_

Curious if there was some technical barrier on Azure, or if it's perhaps
coming later.

~~~
_jezell_
AWS is gold standard so of course they would support it.

Cockroach labs is backed by Google Ventures and run by former Googlers so that
explains GCP.

Azure may not have the most impressive tech stack, but plenty of non tech
reasons for these decisions as well.

------
dominotw
Does anyone have any comparison to other new sql offerings foundationdb, nuodb
ect

~~~
qaq
foundationdb the sql layer was not opensourced as far as I remember.

~~~
skyde
[https://github.com/maximecaron/sql-
parser](https://github.com/maximecaron/sql-parser)

~~~
qaq
look at the dates

------
leibwiht
What a dreadful name.

~~~
dang
Understandable, but there have been so many boring threads about this that we
need to just not to go there.

