We already do that - our backend has some other work to do since we use AWS
Secrets Manager to store database passwords, and also the hostname, so that
our settings.DATABASES does not contain the PASSWORD but must contain a
SECRET_ID. The question is whether this is worth promoting since AWS RD
Hi!
Good to hear about the use of RDS Proxy. I have considered looking at it to
help scaling.
You should be able to bypass the timezone check yourself with a little
subclassing. You can implement this yourself with a subclassed database
backend like so:
https://docs.djangoproject.com/en/4.0/ref/d
Sorry - lest I miscommunicate - the DBAs make the default equivalent to
EST5EDT, rather than UTC. Django team leads (me and David), want USE_TZ =
True to be on for all the applications, and because of this the postgresql
backend will issue SET TIMEZONE UTC in
django/db/backends/postgreql/base
Hi Django developers,
At the National Library of Medicine we are doing a lot of Django and AWS.
For some of the applications with heavier traffic, we are using RDS Proxy
within AWS. RDS Proxy is sort of like a managed version of pgbouncer or
pg-pool-II - it must be rather AWS customized becau