Support YugabyteDB as a State Store

[ashetkar]

Describe the feature

Support YugabyteDB as a State Store.

About YugabyteDB:
YugabyteDB is a transactional distributed SQL database for cloud-native applications. It is wire-compatible with Postgresql. More details here.

Release Note

RELEASE NOTE: ADD support for YugabyteDB as a state store in Dapr.

[berndverst]

If it is wire compatible with Postgresql, can you not simply use the Postgres state store and point it at YugabyteDB? That would be preferred @ashetkar

[berndverst]

According to the docs the GO library lib/pq works to connect. We use jackc/pgx which supports the same required authentication method.

For this reason I do not think a dedicated Dapr component is required to connect to YugabyteDB and we also do not need to update our documentation.

Please just use the Postgres state store.

[ashetkar]

@berndverst Thank you for the response.

The Postgresql component of Dapr makes use of xmin column for etags and YugabyteDB does not support xmin, hence it cannot use the Postgresql component to connect. And there may be other incompatibilities existing.
Also, we may be able to add YugabyteDB-specific optimisations like using our fork of jackc/pgx driver, etc.

Even though this issue was filed to request the support, it was to be followed up with a PR from us that we have already been working on. And we would like to work with Dapr team to complete this support.

Given this, please consider retaining this GH Issue. Do let me know if you need more details, thanks.

[artursouza]

I am reopening the issue for further discussion.

How do you solve the etag in the new component? What are the other incompatibilities? I am wondering if there is a way to make the existing Postgres component configurable and work for YugabyteDB - I think the community can benefit from that - we could even add YugabyteDB to our conformance tests just like we use multiple brokers for MQTT conformance tests.

Now, if you have a fork of the jackc/pgx driver that you would like to use, have you considered making this component as a pluggable component instead? We do have a go-sdk that make this simple if the component is written with the same interface as components-contrib: http://github.com/dapr-sandbox/components-go-sdk

[berndverst]

@ashetkar I would prefer if we add whatever capabilities are needed to the existing Postgres state store.

@ItalyPaleAle created the TTL implementation. We can certainly change it, or conditionally enable / disable it to create compatibility.

Duplicating the Postgres libraries in our code means more memory utilization for something which isn't strictly necessary. What optimizations are there which Dapr would realistically leverage?

If you must create a new component I strongly suggest using the version of pgx we are already importing.

[berndverst]

I agree with @artursouza if you must use the fork of your driver then this should be a pluggable component (a binary external to the sidecar which communicates with the sidecar).

Importing a fork of pgx specifically for Yugabyte is a dealbreaker for inclusion in the binary directly. But a pluggable component would solve this.

I still lean towards just making the existing Postgres component more flexible and not introducing a new component here. After all the goal is to be able to connect to Yugabyte. The component name does not matter.

[ItalyPaleAle]

xmin is a built-in column in Postgres that indicates the version, and it's used for etags in Dapr: https://www.postgresql.org/docs/current/ddl-system-columns.html

I'm happy to consider a switch that uses a different column for etags for YugabyteDB. You may need to manually generate a new etag (e.g. a UUID) before inserting or updating a column, but it would work (please make sure that Postgres can continue using the buillt-in xmin).

Agree with @berndverst that importing a fork of pgx is not an option I'm afraid. pgx is very actively-maintained, and we don't want to depend on a fork which will lag behind.

[ashetkar]

Thank you @artursouza for reopening the ticket for discussion and everyone for insightful comments.

Let me take some time to understand the suggestions (like pluggable component among others) and get back to you with answers/ further comments.

[berndverst]

@ashetkar maybe you can contribute the performance improvements you need directly to pgx and then we can just use the latest pgx version. That benefits everyone!

[ItalyPaleAle]

@ashetkar can you please try with the CockroachDB component and see if that works with YugabyteDB too? I have a feeling it might (and we're thinking of merging that into the Postgres component)