When your go for AWS RDS you can very quickly bring up a database instance and start using it. I’ve written about my thoughts using this approach here and really encourage you to learn about a specific service in more detail before you start using it. If you want to have a managed service for PostgreSQL in AWS, you can go for AWS RDS for PostgreSQL and this service will be the topic for this and the next posts. In this very first post we’ll have a look at DB Parameter Groups as this is how you manage your configuration of database/instances parameters in AWS RDS. There is also the concept of Option Groups but they are not relevant for PostgreSQL as there are no separate options to use with PostgreSQL.
A DB Parameter Group is basically a container for all the PostgreSQL parameters you want to have applied to your PostgreSQL RDS instance and when you spin up a new instance you get a default parameter group predefined by AWS if you did not create any on your own before. That might work well for you but it is always a good idea to review predefined settings and adjust that to your requirements so we’re going to create a new one:
As RDS is a managed service it absolutely makes sense, that e.g. the archive_command is not changeable by the user of the service. Backup and restore implementation details are hidden in the background and this is all managed by AWS, nothing you can do here from a parameter perspective. You can only see that RDS for PostgreSQL uses a Unix like operating system in the background because of the location of the script that does the archiving.
As you do not get access to the operating system that will be running your PostgreSQL instance you can of course not install any extensions. If you need an extension that is not in this list you are stuck and would need to go for a self hosted instance (maybe on EC2).
There are not too much parameters which are read only and you can adjust most of them. What you should think about are which extensions you are going to use and how you want to configure them, e.g. for auto_explain:
Just in time compilation (JIT) is disabled by default, do you want that?:
max_parallel_workers is, e.g., something you might want to calculate based on the instance type as well instead of going with the default of 8:
The same is true for max_work_prosesses:
We’ll not go through all the parameters, the key point here is: Do not trust the defaults but rather create your own DB Parameter Groups, maybe based on your application needs, maybe based on the instance types you chose, maybe based on experience from your on-prem instances. You probably already invested some time in configuring PostgreSQL for your needs and you should do the same here. Apply what you know works best for you and then go with that.
That’s it for now, in the next post we’ll look at subnet groups.