AWS RDS for PostgreSQL – 1 – DB Parameter Groups

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:

A new DB Parameter Group is always based on a “Parameter group family” and that will be postgres12 in our case as we want to deploy PostgreSQL 12 later on:

Once the new DB Parameter Group is created we can go ahead and edit the settings:

You’ll see a list of all the parameters. Some of them can be adjusted by you, others are read only:

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.

There are also parameters that are not known to community PostgreSQL and these are modifications that AWS added, like this one:

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).

Encrypting traffic to and from the RDS instance is prepared in the background as well as you can see it by looking at the read only SSL parameters:

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:

You will also notice the AWS makes autovacuum more aggressive than that is the case in the default configuration of PostgreSQL:

( autovacuum_vacuum_scale_factor is 0.2 and autovacuum_naptime is one minute in the default configuration )

For some of the parameters there is a formula:

The formulas and expression you can use are documented and you usually need to know the instance type to know the final value of the parameter.

Just in time compilation (JIT) is disabled by default, do you want that?:

Are you happy with the RDS defaults when it comes to logging?

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.