Does EdgeDB work out of the box with AWS Aurora w/ PostgreSQL engine?

[ediskandarov-cur]

I'm planning to use AWS for infrastructure.

Does EdgeDB work out of the box with AWS Aurora w/ PostgreSQL engine?

[fantix]

In short: yes!

For basic use cases and most advanced use cases covered by the current server test suite, it's positive they work fine on AWS RDS Aurora with PostgreSQL (12.8 tested, 13 should be fine too). Read replicas are not supported yet, even though you can access the Aurora read replicas directly fwiw. High availability of Aurora is supported now through the Adaptive Backend HA feature, I'll create a PR later to support native RDS HA through AWS API.

[seivan]

@fantix I mean, having multiple EdgeDB instances doesn't exactly the same thing as having multiple endpoints for your RDS instance for read queries, or does EdgeDB do something to mitigate expensive queries and connection pooling occurring to that read replica?

[jackfischer]

Hey @fantix, any update on native RDS HA on the AWS API?

[jackfischer]

Alternatively, would you expect the "EdgeDB read replicas from an application level" technique to work with later versions of edgedb that do writes for the query cache?

[fantix]

@seivan oh sorry I missed your question:

does EdgeDB do something to mitigate expensive queries and connection pooling occurring to that read replica?

It doesn't do so at this moment, but it would be an interesting and feasible feature to add. Still, given the data consistency/synchronization limitations between replicas, designing a generic solution in EdgeDB to balance application tolerance and overall performance can be a bit complicated. Starting one EdgeDB server per Postgres replica would still be more controllable on the application end.

any update on native RDS HA on the AWS API?

@jackfischer Negative, sorry it's not prioritized :(

would you expect the "EdgeDB read replicas from an application level" technique to work with later versions of edgedb that do writes for the query cache?

Yes, that should work; we have all the logistics to synchronize persistent cache among different EdgeDB as "tenants" (as for the same Postgres cluster/replica fleet) done with underneath pg notifications and so on. However, if you have a lot of cached queries, say more than 1000 (_MAX_QUERIES_CACHE), the invalidation may race between tenants IF they have different query variety profiles, resulting in a relatively lower cache hit rate due to the fact that the cache invalidation is currently done in a per-tenant distributed/relaxed way to be fast and simple.

[jackfischer]

Understood on RDS HA support, especially with Cloud coming to market. That's great news on the query cache and so cool to hear how much thought has gone into it.