Hello ! 👋 I am evaluating Ory Kratos and Supertokens. It looks like both can fit my needs, but my main concern in with the DB high availability part. I'm planning on deploying my app on a k8s cluster and using Yugabyte for the DB, and it seems Kratos does not support it according to some old github issue they had. I'm rather unimpressed with Ory's idea of high availability, which pretty much boils down to "we have infinite horizontal scaling capabilities as long as the DB follows, and that's not our problem", and then only allow pointing to a single hostname in the DB connection string. Even if I point to an haproxy or SQL proxy, I can't at least point to 2 and have a least one as a fallback. My questions would be : Can Supertokens be configured with multiple PGSQL targets in the connection string ? And before I go down that rabbit hole and test it myself, is anybody using Supertokens with Yugabyte as DB backend in production?

hey @User Unfortunately, we don't support DB sharding yet and so even with us, you can just point to one DB instance. And we don't support Yugabyte.

hey ! Thanks a lot for the answer 🙂 I'm really trying to avoid single points of failure, without relying on things like load balancers + keepalived, especially for DB connections that can be consistent and will break anyway. It would be great if there was a way to at least pass 2 connection strings in your config, and have the code fallback on the second one if the first one errors, but that's really just my very opinionated opinion 😄 Thanks a lot !

You can actually do that by doing the following: - Deploy two SuperTokens core - Each connected to a different DB proxy service - The db proxy service would (as the name suggests) be a reverse proxy to the actual DB instance. - Now you could have two db instances which the reverse proxy connects to. Both of them connect to the same (primary) instance by default, but in case the default one is down, then fallback on the other one. I'm not sure which service provides a reverse proxy as described above, and I'm not sure about the best way to go about replicating the data across the two db instances. -------- The above would have no single point of failure.

that's a good idea, spawning 2 instances and have my own code round-robin between the 2 of them, yes that would work 🙂

Yup!