CockroachDB 2.0 released | Hacker News Reader

CockroachDB 2.0 released

cockroachlabs.com

299 pointsnate_stewart124 comments

I am genuinely interested in using CockroachDB as a primary datastore but feel like I have been burned too many times by hopping on board with a young database.

I tried lucene based databases that offered amazing search capability but were riddled with data corruption issues. Then there was RethinkDB which was very promising but ran out of funding.

I am skeptical that a networked database with multiple nodes can match the performance of a single master database such as MySQL, PostgreSQL, or SQL Server. I did a quick benchmark of CockroachDB 1.x and MySQL last year and found that CockroachDB was 5-10x slower on simple CRUD queries: https://github.com/caleblloyd/MySqlCockroachBench/wiki/Concu... Are there any good independent benchmarks of performance?

According to crunchbase, Cockroach Labs has raised $53.5m (RethinkDB had only raised $12m). Is there evidence that Cockroach Labs is on track to make money and is going to survive?

If the company is healthy and the performance is verified as close to a major RDBMS, I would be comfortable trying it out as a primary datastore. If those questions can't be definitely answered right now, I'll probably continue to wait for the company and the tech to mature.

> I am skeptical that a networked database with multiple nodes can match the performance of a single master database such as MySQL, PostgreSQL, or SQL Server.

It likely can't unless there is some black magic going on. Single node speed will always be faster. But once you get to that point where a single node chokes on the amount of data or query throughput that you have, you don't really have a choice anymore.

My personal plan is to start with Postgres RDS. Grow until RDS doesn't work anymore, then move to ultra beefy bare metal servers in colocation with AWS Direct Connect. If I ever outgrow an 4x24 core server with 3TB of memory on a RAIDed NVMe disk cluster, I might move to Citus.

For the various distributed database companies out there, I believe the one that will win in the marketplace is the one working or partnering to develop specialized hardware and networking, and then optimizing for it.

> then move to ultra beefy bare metal servers in colocation with AWS Direct Connect.

You will still need another beefy server in another datacenter with configured replication and failover, which is one of the problem Cockroach is trying to solve.

Why not bare metal on AWS? Going to DX is going to give you a conservative 10ms on your calls...

That might be a good intermediate option, but they still don't have instances with 4x24 cpu, or >488GB ram.

Did you look at the x1 options? Up to 128 CPUs and 3,904GB of RAM on the x1e.32xlarge.

Those aren't bare metal. And in terms of database scalability, I would jump for bare metal before beefier servers, due to the fact that the disk is local and you don't have to deal with EBS noisy neighbors.

The x1e.32xlarge has 4TB of SSD in addition to dedicated EBS bandwidth.

I haven't tried it, but IIRC that's only network bandwidth to the block store. Better than the alternative for sure, but I would assume disk access is still noisy unless you have a dedicated drive.

The max IOPS for provisioned EBS is less than 10% the max IOPS of dedicated hardware SSDs.

True, but you do have 4TB dedicated SSD

There is some black magic[0] going on with BedrockDB. They are using a single node at Expensify and getting 4 million queries per second.

[0]: https://news.ycombinator.com/item?id=16118776

A distributed db running on a single node isn't distributed, so that is just showing the performance of SQLite on a single node, which is the point of the thread.

Also bedrock has plenty of problems and is highly unrecommended.

> I believe the one that will win in the marketplace is the one working or partnering to develop specialized hardware and networking, and then optimizing for it.

soo... oracle? :b

You are 100% correct about waiting for several years before using a new database product.

However, if you look at the path Cockroach is taking, they're doing all the right things to shave those years down. They already Jepsen themselves, and they've been doing rigorous testing forever now.

Very exciting.

So did RethinkDB. :(

It's still alive as an open source project, but probably less support now. https://github.com/rethinkdb/rethinkdb

RethinkDB still has a 2 year old critical memory leak that probably won't ever be fixed:

https://github.com/rethinkdb/rethinkdb/issues/5865

And still available as a managed service on Compose: https://www.compose.com/databases/rethinkdb

Touché

Performance is a very tricky thing to measure in a database. CockroachDB's performance is certainly affected by its consistency model. In particular, CockroachDB handles transactions using serializable isolation, and writes using consensus replication. This means that it's difficult to make an apples to apples comparison for performance between a replicated CockroachDB cluster and a single master MySQL server. However, that is the whole point of a well thought out, standardized benchmark like TPC-C. It creates a pseudo-realistic workload, and mandates the use of transactions with a reasonable isolation level or higher (snapshot isolation), carefully calibrated degrees of contention and failures, and then leaves it up to the database vendor to optimize within those parameters.

When Amazon did this for Aurora, they showed that with their custom storage backplane, they were able to absolutely murder normal RDS-based MySQL in terms of TPC-C throughput. Take a look: https://www.slideshare.net/AmazonWebServices/dat202getting-s.... The bottom right quadrant of that slide shows what happens to a standard MySQL server when given 10,000 TPC-C warehouses to chew on (about 800 GB of TPC-C dataset). The max throughput is supposed to be ~128,000 tpmC. RDS MySQL in their tests was able to do 69. That is quite simply, not impressive. Even Aurora, which is a full 136x the tpmC throughput, is still more than 10x less than the max throughput that should be achieved at that number of warehouses.

CockroachDB can scale out, so while it may have more latency when it performs a simple transaction or millions of simple transactions over a small set of data, it can also easily scale to handle 10,000 TPC-C warehouses, with 126,000 tpmC. If you're going to talk about performance, you really need a serious benchmark, or you're just kidding yourself.

Let me put this another way. While Amazon frequently talks about how Aurora can be scaled to 64TB of data, in the context of TPC-C, that's a risible claim. A maximal instance of Aurora, tuned by AWS, can handle max TPC-C throughput at something between 80GB and 800GB of data (i.e. 1,000 to 10,000 warehouses). It's like they're selling you a pickup truck with a bed they say can handle 64 tons, only if you load it that way, it can only travel 2mph, and can't turn. Caveat emptor!

When I tested CockroachDB, I did a single-node and multi-node comparison to Galera. I was ready to accept that multi-node is going to have a performance hit, but what surprised me the most was that the single-node performance was roughly 5-10 times worse with CockroachDB.

https://github.com/cockroachdb/cockroach/issues/17777#issuec...

I just read up on that issue. We will follow up with updated measurements with CRDB 2.0. The big reason for the discrepancies you measured is likely the fact that each sqlbench write transaction is doing six consecutive consensus writes (incl. commit). With CRDB, you need to parallelize your transaction writes using the `RETURNING NOTHING` syntax, which would likely be a significant improvement. This manual tuning is obviously sub-optimal, and will not be required in the next version of CockroachDB (2.1 in October).

A distributed database will never be faster than a single-node RDBMS for simple queries because there is added overhead of coordination between nodes, especially if you're repeatedly writing to the same exact rows.

What distributed databases give you is scalability as data grows, and high-availability for safety. Performance comes from that scale and concurrency when your data and queries fit the model.

Not entirely correct. The distributed database can scale computation horizontally across the nodes in cluster. Single node is better only for the relatively small dataset. If you go higher volumes and velocity, Vertical scaling is still more expensive than Horizontal scaling. If your data is large, with network bandwidth of 1Gbps (or perhaps better) distributed database may choose to replicate it efficiently across the nodes and do scatter-gather (or divide and conquer) query parallelization and also maintain HA. Citus DB is one example of distributed database which does exactly that.

That’s basically what I said...the point is that simple queries on the same keys will never be faster.

There's definitely cases where a distributed database will have higher bandwidth than a single-node database. Since each range is replicated across 3 machines, that means if you have a lot more nodes than 3, the overlap of ranges significantly decreases and you start being able to handle more requests than a single node can.

However, the latency will typically be higher since it always has to talk to at least 3 nodes.

If you consider CRDB's DistSQL which lets you run queries on multiple machines, it might be possible to beat a traditional RDBMS on read latency for large queries.

It would be nice if CRDB could have a mode when 1-3 nodes are active that is similar to since master performance with automatic replication. Then if horizontal scale-out is needed a performance hit could be taken.

I like the automatic replication of CRDB but the vast majority of apps can't afford to take a big performance hit and don't need large horizontal scale-out.

You can run CRDB with only one replica per range. You just lose a lot of reliability if a node goes down.

They also only handle data corruption at the cluster level so there's not really any tools to extract data from a partially corrupted DB on a single node.

I totally agree. So true. Lots of time I ask myself what is the point of compare a single node RDBMS to a distributed database.

Even with MySQL, the replication is still asynchronous from binlog? Is it also the case with postgres?

Yes, postgres has sync and async replication with the ability to even choose a quorum (so that 2 of 3 replicas confirm).

Also has logical replication now, although I wouldnt recommend it because it doesn't support DDL changes yet. Overall it's a solid db choice, but there is still some work involved.

Otherwise I'd recommend SQL Server for a fantastic commercial database that runs cross-platform and has great tooling to make everything easier and some advanced features.

In postgres you can choose if the replication is synchronous or asynchronous. For cascade replication (a slave uses as a master for another slave) the replica is always async.

My general rule: always pick the boring major RDBMS - unless you have a specific reason not to.

High availability with automatic failover is a pretty common reason. To do this with a "boring major RDBMS" removes the boring part and requires leaving the beaten path of the core RDBMS product anyways (or paying lots of money). If multi-master w/ automatic scaling and failover were a first class feature of these boring major RDBMSs, you could have the best of all worlds.

Yeah, I've got a few projects that I'm not doing much where scaling would be an issue, but I really want easy multi-master. I want to be able to have a few database servers and be able to take one offline for maintenance (or because of mishap) with minimal fanfare, without it causing downtime, and without it feeling like I'm performing open heart surgery. There's plenty of ways to fuck up a manual switchover, and I don't want to discover more of them again in production.

Technically, I don't really need multi-master, a "standard RDBMS" with automatic failover would probably fit the bill, but I could not for the life of me figure out any standard (and free) way of doing that for mysql/mariadb or postgresql.

Do you need a distributed database for your use case? Or do you like the new tech? Genuine question, not trying to be snarky.

I do not have a particular project in mind, but think it would be good to have an easily containerizable, replicated OLTP database in my toolkit. I do some work with Entity Framework Core providers and am thinking about trying to implement a provider for CRDB.

There is already some work towards this with http://www.npgsql.org/

I haven't gone back to try the full entity framework recently, but if you find any bugs, please let us know. If you want to roll your own, we're here to help too.

CRDB is using the Postgresql wire transport and already works with npgsql + ef core.

Are you sure? I know that the NPGSQL DB driver works with CRDB. Data types, DDL, and supported features are a big part of EF Core providers though. I have not researched it yet but I was pretty sure the NPGSQL EF Core Provider implemetation was just for PG.

CockroachDB uses the same PostgreSQL wire protocol and SQL dialect so it just looks and works like a pg database. There are some minor differences but DDL and data types are already included in the syntax: https://www.cockroachlabs.com/docs/stable/porting-postgres.h...

It's great if you want to contribute though but I'd recommend just working on the PG EF Core provider which already has some work towards CRDB specific features: https://github.com/npgsql/Npgsql.EntityFrameworkCore.Postgre...

Great, thanks for the info. I have worked with @roji before on EF Core upstream issues, NPGSQL EF Core is very good. I will reach out to him!

It's really to sad RethinkDB gone.

While I keep hearing that the RDMS(Postgres, MySQL...) was built on year of experiences I alwawyas think why we cannot come up with something nicer, more friendlier to the old way. Eventually we will build up knowledge on the new thing and have a system that just as good but also as much friendlier.

Example: when looking at how MongoDB handle replication, it's so easy to just add a new node and have it join cluster without seeding some data and set binlog position (like MySQL).

Or looking at RethinkDB query language, it's just so much easier compare with SQL, at least to me.

Nowsday, I cry whenever I see SQL query. I learn to master it, but life's too short to write those kind of thing.

But, this is a thing in life when you are simply wrong. So find a way to learn it or remain a subpar dev.

> I am genuinely interested in using CockroachDB as a primary datastore but feel like I have been burned too many times by hopping on board with a young database.

> According to crunchbase, Cockroach Labs has raised $53.5m (RethinkDB had only raised $12m). Is there evidence that Cockroach Labs is on track to make money and is going to survive?

I'm in a similar situation: new project, CRDB is a good fit on paper, but I'm unable to get traction even for a proof of concept exercise because of the risk associated with a database backed by a startup. This is at a large, conservative, 300k+ employee company, so I guess it's understandable... but regrettable nonetheless.

See you guys in 5 years ;-)

Becoming a paying customer is a way to help them survive.

When it comes to databases, always wait for the Jepsen test!

https://jepsen.io/

CockroachDB underwent a Jepsen audit by Kyle Kingsbury before its 1.0 release. Check out the blog post[0] and Kyle's analysis[1].

We also run Jepsen tests against the database nightly, ensuring that its isolation guarantees do not regress.

[0]: https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-j...

[1]: http://jepsen.io/analyses/cockroachdb-beta-20160829

Which they've been doing for around 2 years at least

https://www.cockroachlabs.com/blog/diy-jepsen-testing-cockro...

As others said, Cockroach's performance is limited by its consistency model. It is not something that can ever get close to a single master MySQL. This might also become an issue for the company and ultimately prevent it from reaching mass adoption and succeeding, at least commercially.

I think the combination of Cockroach and Kubernetes is going to be a game changer. Modern orchestration tools really are still struggling with single points of failure and Cockroach really shines there. The fact that both tools are maturing at around the same time is a real win for Cockroach. Additionally its use of certificate authentication just fits in with the rest of Kubernetes.

How does Kubernetes help with failover?

It's distributed, with no single point of failure. Your machines or vms that manage the cluster (should be) separate from those running the containers.

Ideally you set up 3 master nodes, with distributed etcd cluster for state, and enough machines to run your services with replication.

All of which is not bad at all to get started with if you use something like Kops.

Some useful docs: https://kubernetes.io/docs/admin/high-availability/building/

Geo-partitioning seems to be the killer feature here especially with GDPR looming. Perhaps I'm wrong, but I'm not aware of any other DB which makes physically locating records in a particular region so easy.

You can create geo-zones for your MongoDB shards. [1] It has pretty powerful geo-spatial queries too, but that's unrelated.

[1] https://docs.mongodb.com/manual/tutorial/sharding-segmenting...

I find it very interesting that although CockroachDB itself is stable and production ready, all of the client drivers are still 'beta'.

https://www.cockroachlabs.com/docs/stable/install-client-dri...

That being said, I am really excited to try this out. 2.0 adding JSON support is what converted me to try this out for a project.

It uses the postgresql interface so any Postgres compatible client should work. The status just refers to esoteric features that may not be supported.

We marked these drivers as beta support to indicate that we haven't tested them to the same rigor as our internally developed features. Basic querying and transactions should work with any of these drivers, but features like introspection and less commonly-used data types haven't been extensively tested across all drivers. Many people report using these drivers in production, however, we've prioritized new feature development for CockroachDB over extensive driver testing. We encourage you to give these drivers a try and let us know if you encounter any issues--we'll be happy to fix any bugs brought to our attention.

They haven't any custom driver, CRDB is binary compatible with postgresql drivers, are marked as beta because "maybe" there is feature they haven't implemented. So far using pqxx (C++ driver) I haven't seen any issue.

it uses standard, off the self postgresql libraries. but their server-side implementation of postgresql isn't 100%. or even 98%, so you can't count on every feature of every client library working.

Most seem to just be postgres drivers.

Congrats on the great advancement. It's also a coincidence that TablePlus just started to support CockroachDB yesterday. In case someone need a good GUI: https://github.com/TablePlus/TablePlus/issues/374

Congrats on a major achievement, CRDB! It’s been really hard-core and cool stuff! Super excited to see that one more use case is coming in, the one with the Blockchain! In case someone is interested, TiDB released a case study with Mobike (with a daily data growth at ~30TB) just one day before: https://www.pingcap.com/blog/Use-Case-TiDB-in-Mobike/

Tangentially related - I would be interested in hearing anyone's experience so running CockroachDB 1.x in production.

Question on the efficiency of inverted indices for Cockroach json tables - if you do a query for identity on two of the fields, like searching for all json documents containing `{a: 1, b: 2}`, how efficient is that? Will it essentially only use one of the indices on a and b, or will it work like a sql multi column btree index?

Good question! In 2.0 we only use one of the fields for the index lookup and then use the rest as a filter. For 2.1 we’re planning on augmenting our execution engine to enable making use of all the fields in a more efficient way. We have an RFC[0] describing the way our inverted indexes are designed, though not everything outlined in that document is implemented yet.

[0]: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

Here's a different take on databases.. Which is easiest to manage for a shop with minimal DB knowledge.

That seems like a scary situation, .. and you're correct. It doesn't change the reality though, heh.

So how does Cockroach compare to Postgres, or Maria, TiDB, etc on ease of management? Any thoughts?

If you want rock-solid stability? Just use Postgres. Decades of production use, experts easily available, and scales very high on a single node. Replication and backup are solved and there are lots of extensions for more functionality. You can also try the hosted options which all cloud vendors have, or I recommend Aiven.

Don't use any distributed relational database unless you actually have a need for it, like horizontal scalability for massive data, multi-regional access, or 100% uptime guarantees.

Appreciate the insight

Honorable mention - CitusDB It installs as Postgres extension and supports parallelization of queries across nodes. https://www.citusdata.com/

Can someone explain the inner workings and thus tradeoffs it makes? And how it would impact when and how you'd want to use it?

The FAQ on the website is a good place to start:

https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

When is CockroachDB a good choice? CockroachDB is well suited for applications that require reliable, available, and correct data regardless of scale. It is built to automatically replicate, rebalance, and recover with minimal configuration and operational overhead. Specific use cases include:

Distributed or replicated OLTP Multi-datacenter deployments Multi-region deployments Cloud migrations Cloud-native infrastructure initiatives

When is CockroachDB not a good choice? CockroachDB is not a good choice when very low latency reads and writes are critical; use an in-memory database instead.

Also, CockroachDB is not yet suitable for:

Heavy analytics / OLAP

I guess I was hoping for the engineering expert FAQ.

What level of reliability, how, what tradeoff in my table design will I need to make, same thing for availability, correctness and scale.

None of the info in this FAQ allow me to know that CockroachDB is the right choice for me against the competition which advertises the same generic DB marketing terms.

Edit: And yes, I can go and read the documentation and deep dive into the internals myself, but I don't care enough to do so, because I already have DBs that fulfill those use cases that I know off, and I would hope therefore that CockroachDB would make it very quick, easy and in my face to find the info that will make me go: Ah Ha, this is the distinguishing factor and the reason why I might want to favor and care to use CockroachDB the next time I've got such a use case.

Is community edition build capable of Multi DC ?

Yes, but for multi DC you will probably want many of the tools in the enterprise edition: https://www.cockroachlabs.com/pricing/

There's a noticeable lack of pricing on that "pricing" page...

I see. Thanks.

For those in the area, the CockroachDB folk are hosting a meetup demoing some of the new 2.0 niceties: https://twitter.com/CockroachDB/status/978701442050592768?s=...

I thought the name was weird and found this:

The name was chosen in 2012, two years before the open source project was started. I had just gotten done with an exhausting and ultimately frustrating survey of OSS database products for the backend of a new private photo sharing service called Viewfinder. I'd tried and found wanting MySQL, Postgres, AWS SimpleDB, Hbase, Cassandra, and Riak.

I was annoyed. Why wasn't there a scalable, survivable, consistent database with transactions? I was even willing to drop transactions as a requirement – a terrible sacrifice. The frustration led me to write a manifesto. What would the "right" database look like?

I imagined it would be composed of symmetric nodes, require no external dependencies, spread itself naturally across availability zones for survival. Each node would autonomously replicate and repair data. These were the capabilities that led me to the name "cockroach", because they'll colonize the available resources and are nearly impossible to kill.

- Spencer Kimball

Cockroaches are actually very easy to kill/exterminate, if you do your research. Their dogged replication and consumption strategy is their Achilles' Heel.

The unkillability of cockroaches is highly exaggerated. And for dogged persistence, I'd give the crown to the humble fruit fly.

Can mods just delete comments about the name of this project? It's getting absurd.

One could argue that if the creators didn't want a constant discussion around the name every time they tried to promote it, they would have chosen a better name.

I don't think we should be censoring a discussion just because you've already had that particular discussion.

I think it’s a brilliant decision. It serves as bait to separate the vapid, superficial commenters from those who are actually interested in the technology.

I'd bet good folding money that they change it at a certain growth point, and I'll take it as a good sign when they do.

How much you want to bet? I’ll take 50/50 odds.

Accidentally genius marketing.

Obviously they didn't anticipate constant naming discussions.

the name is apt though. Your data IS the cockroach. You can't kill it and it replicates easily. I guess they could have called it cancer instead? ;)

It’s an insult to roaches to liken them to cancer. They’re not particularly destructive. Termites are more like cancer.

The name is dope. Roaches suck when you have them in your house but they’re a cool species. When all is said and done and the sun is going red, this planet will still be host to a few species: humans, rats, and roaches, among others.

People hate them, but they’re one of the animals most similar to us. We hate them because we don’t like to admit our nature.

The name keeps coming up because it is _that_ bad. Sometimes when you see a message repeated, it's not because people are stupid.

Do you really think annoying comments on HN are the anomaly where people care about the name? Or is it in itself evidence that there is some percentage of the population for whom the name is an obstacle?

sounds to me like the blockchain before blockchain. i personally feel blockchain hasnt lived up to its potential because it cant yet act as a viable database. i am curious to see who would take that throne . potentially cockroachdb seem to be in a good spot for that with some adjustments.

It wasn't before blockchain. Not everything distributed and fault tolerant is blockchain. You can't sprinkle blockchain fairy dust on problems unless your problems are insufficient hype.

Is there any good abbreviation or a nickname for this DB?

Initially I thought I could get used to it, but after many years watching in HN I haven't succeeded yet.

Perhaps you cut the word in half, but it just creates another two strong words and shows the survival power of the word :(

Calling it CDB doesn't click to me either.

We call it CRDB internally

I've seen CockroachLabs refer to it as CRDB.

I've seen people referring to CockroachLabs referring to it as CRDB internally.

Queue the comments about it's name...

Congratulations to the CockroachDB team. I have been using this on a few projects. I find the ease of scalability and redundancy very nice.

Also, the ability to use SQL commands on a transactional DB is REALLY helpful.

Keep it up.

I wouldn't use it because I just don't want to see and write its name daily.

People are downvoting you, but there's something to be said about it. What happens if you try to pitch CockroachDB to your non-techie upper management? They're going to look at you like you're an idiot. Names aren't important unless they're bad because first impressions do matter.

I think the opposite. The name makes it easier to describe what it does to people that doesn't understand the technical vocabulary.

In this case, with the connotations that the name "coach roach" is associated with, you'd be wrong:

https://www.huffingtonpost.com/molly-reynolds/why-brand-name...

The only connotations I've got with cockroaches is resiliency, and maybe hissing?

I guess that does explain the custom support for

    PRAGMA hissing_noise();

> They're going to look at you like you're an idiot.

Are they really going to? As someone with many years of marketing/branding/advertising experience, CockroachDB is a bold, powerful and meaningful name, that, in my opinion, is one of the best branding cases I've ever seen for tech infra products.

Say "CRDB" and move on with your day.

While I agree with the spirit, and don't share gp's attitude, that probably wouldn't be effective for web search.

How often do you pitch the name of the tools you use to upper management? I just say we are going to use a database.

I'm guessing that the downvotes are because people consider the stated reason to be a terrible one.

Your point, which is that other people may use the same justification, doesn't validate the point. It just means that there may be more than one person who would use the same, poor, reason.

are people really serious when they say they won't use the product because of its name or is this some kind of HN meme where everyone complains about the name everytime there is an article on cockroachDB

I think they're being serious. Names are important, not as much as the underlying technology, and I think some people legitimately would be embarrassed trying to pitch a DB with the name Cockroach, or their phobia could be so extreme that the name itself does affect them. People can argue all day about the name, and HN can get all upset that its brought up everytime a post about CockroachDB is made, but that should say something about the name itself. If the name warrants comments on it, then maybe that means there is some significance to its name and to the general populace.

I think someone should fork it and use Palmetto Bug in the name instead in some creative way. It'd be keeping the spirit of the original name while also not having the same immediate disgust some people have with the name. In South Carolina, a common name to refer to cockroaches is the Palmetto bug.

For example, I wouldn't mention it on my resume.

You would want to work for people who hadn't heard of it?

I would. It would make for excellent interview fodder.

I refuse to use it until they change the name. It's disgusting.

Cockroaches are awesome! The name[0] is sort of a back-formation from a loan word cucaracha which simply refers to a beetle. But in English it takes on a new meaning because of the word "cock" which gives it a real badass connotation, and these things are indeed badass. Now we also have the shortened word "roach" which is also an awesome word for the language. BTW, in SC2 you will want to look out for 6 or 7 Roaches[1] knocking down the front door of your base[2].

Back to the awesome creation of God[3] commonly known as the cockroach. According to Wikipedia[4], there are some 4600 known species of cockroaches, and only 30 of them are associated with human habitats. The rest of them are basically outdoor roaches, so if you find one in your house they are probably there by accident and trying to find a way out.

In fact, the only species you really need to worry about is the so-called "German" cockroach, which Germans call the Russian roach, and Russians call the Polish roach (and I'm sure the Poles blame the Turks or some such group).

If you see this roach in your house then you are in trouble. They like dirty houses so clean your house. And they have evolved to avoid sweets so you have to buy the correct kind of bait[5]. I like to spin long yarns about my battles against these bugs to anyone who cares to listen. In the end you need to deal with the humans who are too friendly to these roaches. Look for college students who live 3-4 to an apartment and go home for the weekend, people who work long hours and leave bags of half-eaten fast food in their open trash cans, and other unfortunate neighbors. Knock on their door and give them packs of the aforementioned roach bait to leave around their dwellings (this requires some tact). In time you can certainly eliminate them, thanks to modern chemistry. It should cost less than $50 and a few months of vigilance.

Frankly the German roach doesn't really fit the profile of your average cockroach. It's slow and seems to be asking you, almost daring you, to kill it, knowing there are 20 others that will take its place. A standard cockroach is the kind that runs away really fast, and would be just as happy living outdoors. They are far more widespread and just as survivable as the pest species, and lend their name to an awesome database product that will probably outlive discussions about its name.

I for one hope the creators keep the name and use the human revulsion about it as a marketing benefit. No one will forget their encounter with the mighty cockroach, and business people will come to associate it with sustainable competitive advantage which cockroaches have in spades.

[0]: https://www.etymonline.com/word/cockroach

[1]: http://liquipedia.net/starcraft2/Roach_(Legacy_of_the_Void)

[2]: https://www.rockpapershotgun.com/2010/11/02/genetic-algorith...

[3]: Genesis 1:24-25

[4]: https://en.wikipedia.org/wiki/Cockroach

[5]: https://www.amazon.com/Combat-Month-Roach-Killing-Station/dp...

Competitive advantage to everyone else. Survival of the cockroach-est.

Well, it is open source, you can just fork it and rename it to, say, ButterflyDB. ;-)

The connotations that the name "coach roach" stir up aren't positive. People are grossed out by coach roaches.

The good news is that DBs are a niche of their own and as such don't need to appeal to the masses, making the name choice somewhat less important. But I still think, as someone else already pointed out here, that selling an exec (or non-tech decision maker) on this will be just slightly more difficult because of the name, as irrational as that might seem.

Google seemed like a stupid name the first time I heard it...

Well that's silly.

I think names are important. CockroachDB and GunDB both chose names that will hurt their acceptance. I often wonder how intentional it is for open source projects to choose strange names (GIMP, etc). Is it a defense against having to fit in with "mainstream" perspectives?

Also, I wonder why Apache doesn't change their name. It would be a good opportunity for rebranding.

Reposting this to see if anyone could comment (last time i promise):

So. For me, personally, I don't care about the name. I generally care that it's great tech, and it clearly has a great team behind it. However....

If I worked at CockroachDB, and I saw the negative feedback around the name, I'd take it to heart. At the end of the day, the name is marketing for the hard work of their engineers, and marketing for the engineers that want to use this DB (remember, they need to sell it to their managers who may not be technical).

This issue can show up in unexpected ways. For example, for cloud providers like Compose (IBM company), would they be comfortable with putting "CockroachDB" on the front page? They might if it's good enough, but it's at least a consideration (i.e. another meeting, another stakeholder to convince).

Or how about an enterprise company that's going through due diligence, and when their client asks them about their tech stack do they say "CockroachDB" or do they obfuscate the name by saying "It's a high-performance distributed database". That's a crucial moment to market CockroachDB, and it could get lost. As sad as it is, saying that you're using MySQL "because Oracle" is a point of leverage for some sales people.

Is the name worth it? Asking honestly.

> I saw the negative feedback around the name, I'd take it to heart.

You shouldn't, marketing is not about your personal feelings or feedback on your marketing. Cockroach name is clearly superior to every other database name, look how memorable it is and how much buzz it generates.

Reply on news.ycombinator.com