Hacker News Reader

Comment by makkesk8 | Hacker News Reader

It's a good move and I even welcome it. However, I would have loved to see the removal of their enterprise version of the product at the same time. I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore feature, which is currently locked behind their enterprise version. I also would love to use CDC and table partitioning. Nevertheless, great product.

View on HN

Never used CRDB so this question may make no sense, but given it builds upon Postgres (AFAIU), couldn't you use any of the many backup solutions Pg offers?

It uses the Postgres wire protocol, but isn't based on Postgres under the hood

CRDB is compatible with the PostgreSQL wire protocol, so you can use existing database drivers (in C#, Golang, whatever) to talk to a CRDB instance. The SQL itself is slightly different (no two databases are the same these days), so that would have to be adjusted.

If your backup solution is fine with "SELECT * FROM table1; SELECT * FROM table2; ..." you can use the client interface for backups. But usually you want to a snapshot of the entire database at some (self-consistent!) point in time, and back up that.

This makes more sense, thanks. I just realized I mistook cockroachdb for timescaledb.

Would ZFS snapshots work? It is what I use to backup PostgreSQL, much easier and faster than ordinary backup

Not unless you like pain. CockroachDB is distributed and uses Raft consensus under the hood, so you can't take a snapshot of just one node; you need to take a snapshot of all the nodes in your cluster, and you need to take those snapshots at the same logical instant. If the snapshots are from slightly different moments, when you boot the cluster up from the backup, the nodes will panic because you'll have corrupted the Raft state or otherwise caused the multiple replicas of the data to become inconsistent with one another.

There is one safe way to make this work: turn off your cluster, back it up with ZFS snapshots, then turn it back on. (Some of Cockroach's production tests do exactly this, in fact, because restoring from ZFS snapshots is so unbelievably fast.) But if you have the flexibility to power cycle your production database off and on in order to back it up... you probably don't need a distributed database, because fault tolerance likely isn't among your requirements.

(I'm a former CockroachDB engineer.)

> But usually you want to a snapshot of the entire database at some (self-consistent!) point in time

This is actually super simple to do in Cockroach, as it supports time travel queries - https://www.cockroachlabs.com/blog/time-travel-queries-selec...

So you can run a script at, say, 12:05 AM every morning, saving the table state “AS OF SYSTEM TIME 12:00” (simplifying syntax). And thereby get a fully consistent snapshot of all tables, as long as your backup script takes less time to execute than the configured table TTLs

CockroachDB is a proprietary database built in Go using RocksDB for the storage layer. It just uses the PostgreSQL protocol so it's compatible with existing drivers and applications but the underlying tech is entirely different.

Advanced backup restore is definitely blocked, but they do provide a `cockroach dump` utility, if that helps.

Making a project that was Open Source, not Open Source anymore, is hardly a "good move". I mean, it might be a good financial move for Cockroach and their VC's, but I have a hard time seeing it as good for the world in general.

If it helps with increasing resource allocation to the project it can be a good move for the world as well. Currently resource allocation is sponsored by VCs, but this can't continue forever.

For the world in general, indeed, it is better than having a dead or hardly-maintained project (which needs financial incentives from project owners). Don't you agree?

I don't really think increasing the world's stock of proprietary software is something to laud. Still, with their "switch to Apache after 3 years", I guess that this is still, on balance, better than nothing.

What I reject is the idea that the only choices are "make this kind of switch" OR "having a dead or hardly-maintained project". Sounds a bit "fallacy of the excluded middle" to me. But they have the right to license their thing however they want, so what right do any of us really have to complain. I just find it frustrating to see people retreating from an Open Source position given my own deeply rooted ideological bias towards F/OSS.

> What I reject is the idea that the only choices are "make this kind of switch" OR "having a dead or hardly-maintained project". Sounds a bit "fallacy of the excluded middle" to me.

In general, that's of course obviously true. For software like this, that's geared toward use by businesses and SaaS applications, I agree with Cockroach Labs. Their hosted solution doesn't stand a chance if AWS decides to do a hosted version of CockroachDB, and they won't see a penny of that revenue. Since contributions outside of employees of Cockroach Labs are pretty minimal, it's a textbook recipe for eventual project death.

> But they have the right to license their thing however they want, so what right do any of us really have to complain.

Correct. And yet that doesn't seem to stop some people...

> I just find it frustrating to see people retreating from an Open Source position given my own deeply rooted ideological bias towards F/OSS.

I get that, and at some time in the past I probably agreed with you. At this point I'm too cynical to believe that Free Software can succeed solely on its merits. The economics just don't work out, especially when you're in a part of the industry with a lot of competition.

And regardless, the new licensing terms are (in practical terms) identical to Apache for the vast majority of people who already use or might use CockroachDB. All they're restricting is the ability to create a Cockroach DB hosting business, and if you really want to do that, my moral position is that you should be financially contributing back to the DB anyway; otherwise you're taking freeloading to an extreme degree there.

I understand why this is the default assumption that people tend to make, but I'm not sure this analysis goes deep enough. I believe things are more nuanced than "you can't compete with Amazon". There are always a lot of different axes on which you can segment a market, and different attributes on which one can compete. And ironically, the fact that AWS (and other public cloud providers) exist simultaneously makes it easier to run your own cloud based service. And yes, it's possible to have something hosted on AWS while Amazon compete with you at the same time - see Netflix for the obvious example.

Note that I'm not saying it's easy to do any of this, and maybe a thorough enough analysis would reveal that, for CockroachDB it really is the case that "we can't compete in a market where AWS is playing". But I wouldn't necessarily take that as a given without having done a lot more research.

> Making a project that was Open Source, not Open Source anymore, is hardly a "good move"

Why? You offer no explanation.

I think it is a good middle ground, it has a very targeted restriction and reverts back to Open Source after 3 years.

I don't believe any explanation is required.

Reply on news.ycombinator.com