4 ms·

> I'm stuck with CockroachDB for the time being. Would you care to share any negative experiences you've had with CockroachDB? What is motivating your desire t

• bithavoc 7y ago
  A few weeks back after my attempt to switch to Yugabyte I decided to commit to CockroachDB in a dedicated cluster with TLS, my backend runs migrations including creating the database but only admins and root are able to create databases but because TLS was enabled my root user didn't work anymore. I was not able to create more admin users because that's part of the RBAC Enterprise offering. The database was there but the authorization system triggers before IF NOT EXISTS condition, so I had to make changes to make it work in production. I honestly thought that if I stayed away from Enterprise features then I would be fine, but no: it seems like if I wanted to deploy my backend on-premise, the deployment process would have to include an step to run the CREATE DATABASE script out of band either before enabling TLS or via localhost(?) in a database node, otherwise I'm fucked unless the client buys CRDB Enterprise to smooth out the deployment process. That's a very extreme case of Open-Core money-squeezing shit I would like to stay away from. CockroachDB Core is fine as a product, the docs are up to date and it's not hard to operate, all that is appreciated it. I just don't think I'm the target user, unless you make a shit ton of money as you scale it will be hard to operate without: - Distributed Backups(Enterprise) - Follower Reads(Enterprise) (no, follow-the-workload doesn't cut it) - RBAC(Enterprise) Yugabyte offers all that in their open-source license, which is why I'm rooting for them, that in addition to Change Data capture(Enterprise offering in CockroachDB) is also included.
  • knz42 7y ago
    Hello bithavoc, I happen to be currently working on that area of CockroachDB and I would like to help. To start with, any scenario that you find where a secure deployment without an Enterprise license makes you unable to operate your apps using the core features, would be a serious bug on our side and we'd give it high priority. There is no intent to do bait-and-switch here. If I read between your lines I can see the following: - you need an admin user to create databases; - the only admin user is root; - it appears that you cannot log in with root on a secure cluster (TLS enabled). Is that understanding correct? I think I understand the following: your SQL client is attempting to connect using TLS but without presenting the root client cert to the server. The root client cert is a cert that you can generate using the cluster's CA key (using the `cockroach cert` command). Without a valid client cert, the connection is refused. You may think this seems to work for other users than root. This is because for other users, when cert validation fails, the server allows the client to use a password instead. This choice to use a password is not available for the root user up to and including 19.2. Here is your way forward: - either you configure your SQL client that creates database to present the root client cert to the server. This will enable you to use the root account on a secure server and create databases (and other users, and then assign privileges to these users over the new database). - or, you wait until crdb 20.1, where it will be possible to configure a password for the root user and let root clients use password authentication instead of presenting client TLS certs. Does this help? If it doesn't please create an issue on github and describe your situation in more details and cc me (@knz). Thank you
    • bithavoc 7y ago
      Correct, I’m using TLS with password authentication, I don’t want to generate certs for my backend user, so yes, root password authorization solves the issue. I can wait for 20.1, should be coming up this month right?
      • irfansharif 7y ago
        v20.1 is slated for release in April.
• contrahax 7y ago
  Lack of geospatial/postgis compatibility is a sore spot for many use cases.