Since Postgres has been around for such a long time, there’s a very wide surface area of features that we will take a while to catch up on. For that reason, it’s difficult to specify a hard list of Postgres features to avoid. Our goal is to get to a place where for the most part, Postgres apps will just run on Cockroach with no fuss, and we’ve been working towards that steadily (for instance, our upcoming 2.0 release will include sequences). As far as ensuring that you’re not stepping outside the bounds of our compatibility, it’s difficult to give a precise answer since we’re constantly improving our compat, the only sure way I think would be to test against Cockroach every once in a while to make sure that your app works with it (and let us know the ways in which it doesn’t!).
As far as non-compatibility answers go, largely this question depends on what you expect to need to switch to Cockroach for. For instance, your example of storing the country and domicile - are you expecting to have to deal with GDPR restrictions? In that case, there are additional restrictions on how you need to structure your schema, since geopartitioning requires that the region a row is restricted to is derivable from a prefix of its primary key. Can you share some more details on what you’re thinking?