![not in postgresql not in postgresql](https://i.stack.imgur.com/BzR8V.png)
Compatibility with anything is a choice, it is not inherently necessary when building a SQL RDBMS. Although Google’s Spanner’s SQL dialect is inspired by MySQL, it is not fully compatible with it either. Why is CockroachDB compatible with anything at all?ĬockroachDB could very well have been created with its own SQL dialect and/or network protocol.
![not in postgresql not in postgresql](https://www.postgresql.org/media-archives/img/about/press/elephant.png)
I was lucky to sit next to Cockroach Labs Chief Architect and Co-Founder Ben Darnell when Lakshmi Kannan, now the general manager of CockroachDB Dedicated, asked us the very same question: Why was CockroachDB designed to be compatible with PostgreSQL? What follows is an extended rewording of the resulting discussion.ĭisclaimer: this is a personal recollection written without notes and after a week had passed. Any inaccuracy in the ideas, arguments, timelines, statements, facts or opinions recollected here is entirely mine. Perhaps surprisingly, at the time of writing (early May 2018), the answer to this question had not been documented publicly on the CockroachDB website, nor in the CockroachDB docs, nor in CockroachDB-related articles in third party sources. Why is CockroachDB compatible with PostgreSQL? And then take a look at the original reasons for the decision.
NOT IN POSTGRESQL FULL
Check out the latest documentation to see the full scope of our compatibility. Customers of ours often reference our PostgreSQL compatibility as a reason why the CockroachDB learning curve is so swift. It’s been three years since this blog was originally published and we’re still feeling great about our decision to prioritize PostgreSQL compatibility.