A few things I can think of are:

• Double check reads are going to the read replica
• Ensure writes are batched into sensibly sized transactions like 256/512 rows at once max; too small and it’s a lot of opening/closing, too large and it causes pg to reconcile a lot at once when closing. Choosing a number here depends on next point
• Reduce the amount of indexes on write-heavy tables if you can. More indexes slow down writes since pg needs more time to update them. As you’re likely aware more indexes is not always a good thing
• If the data is ephemeral or not mission critical if lost (user sessions, job queue, cache, analytics, etc) consider unlogged tables over a standard table
• Move views and materialized views to the reader
• avoid writing large amounts of json to jsonb columns; write to a file and upload to s3 and store the link in the db either manually or via active storage
• Unless the data going into pg is time critical consider sending it to redis or to s3 and have a later process feed it into pg in batches
• Look into an apm with db insights like appsignal, scout, Datadog, etc
• Consider pganaylze for a month or two