Cockroach specific persister

[zepatrik]

Is your feature request related to a problem? Please describe.

It might be useful to have a cockroach optimized persister for truly distributed (multi-region/multi-cloud) settings. Only cockroach (from our currently supported databases) can be used in such a setup. We should investigate if we can leverage some features from it. As far as I can tell there is nothing comparable to spanners "true-time" at the moment.

Features we can use and for what reason

• Fine tune the cost optimizer to reduce latency
• ...

[nathanclayton]

It looks like you support the general PostgreSQL protocol - if that's the case you could also look at YugabyteDB - it supports multiple region/cloud while being a more or less drop-in replacement for Postgres.

[zepatrik]

Sure, that can be used as well. Cockroach can also be used as a drop in replacement of postgres.
It is more about specific distributed features available on top of that like follower reads or the afore mentioned cost optimizer. A list of such yugabyte features might be helpful as well.

[jameshartig]

Yugabyte recently added follower reads as well: yugabyte/yugabyte-db#5232. Not sure about the cost optmizer.

[robinbraemer]

I'm a database nerd and have used Yugabyte and Cockroach alot and read about benchmark comparisons and am not satified with Yugabyte from the deployment perspective (k8s) and perfomance wise. Considering the goal for Keto to support "Google scale" Cockroach is a much more suitable database designed for global distribution developed by amazing engineers.

Nevertheless, it's PostgreSQL syntax at the end, which both databases support. I just want to make sure that everyone does its research and is not misslead by Yugabyte's marketing containing false assumptions manytimes and incomplete benchmarks.

[aeneasr]

Nice, thank you :) We also had our fair share of issues with CRDB and it's quite difficult to get answers from core engineering even as paying customers. For example, the current table-separated model does mot scale at all with CRDB as CRDB is optimized for few large tables instead of many small ones.

[robinbraemer]

Interesting! I'm also currently trying out the much hyped dgraph database. Maybe it's even more suitable since ACL are essentially graphs, deeply nested ACL lookups are a natural efficient lookup. One issue with dgraph might be the multi-region scalability, but this may be added at some point in the future. Exciting stuff!

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[aeneasr]

Our current database design thinking does not require an additional persister for Cockroach. Closing for the time being.