Instance Parameter Reference

Reading an instance class as a set of parameter values

A managed database instance class looks like a two-column fact — so many vCPU, so much memory — but it is really a set of decisions already made for you. The memory figure alone fixes the connection ceiling, the buffer cache and the planner's view of the world. This table shows every instance next to the parameter values its memory implies, so you can read a class as the configuration it actually is.

How it works

• Lists every instance class in the catalogue for the cloud you pick, sorted from smallest to largest.
• Shows memory per vCPU, which is the quickest way to tell a general-purpose class from a memory-optimised one.
• Gives max_connections per instance, computed from that provider's published rule and the engine you select.
• Shows shared_buffers or innodb_buffer_pool_size and effective_cache_size, derived from the RDS default expressions.

columns and where each comes from
  vCPU, memory     the provider's instance class table
  GiB / vCPU       memory divided by vCPU
  max_connections  the provider's published rule for the selected engine
  shared_buffers        25% of memory   (PostgreSQL)
  innodb_buffer_pool    75% of memory   (MySQL)
  effective_cache_size  75% of memory   (a planner hint)

Worked example

One instance class, db.m5.2xlarge with 8 vCPU and 32 GiB, read on both engines.

1. memory per vCPU = 32 ÷ 8 = 4 GiB, the general-purpose ratio
2. PostgreSQL: about 3,324 connections, shared_buffers 8 GiB, effective_cache_size 24 GiB
3. MySQL: about 2,518 connections, innodb_buffer_pool_size 24 GiB
4. the same hardware, two engines, and the buffer allocation differs by a factor of three

PostgreSQL keeps 25% for itself and leaves the rest to the operating system's cache; MySQL claims 75% for InnoDB because it does not lean on that cache. Neither is a tuning choice you get to make casually — both are consequences of picking the class, and they are why the same instance behaves differently under the two engines.

Reading the result

• Memory per vCPU tells you what a class is for. Around 2 GiB per vCPU is compute-oriented, 4 GiB is general purpose, 8 GiB and above is memory-optimised — AWS's r-classes, Azure's E-series. For a database the higher ratios are usually the better value, because memory buys both cache and connection headroom.
• Azure's B1ms is the one row that does not follow its own pattern: 50 connections where the per-GiB rule would predict far more. This table reproduces Azure's published values rather than fitting a curve, so that anomaly survives instead of being smoothed away.
• The t-class on AWS and the B-series on Azure are burstable. They accumulate CPU credits while idle and throttle once the credits are gone, which makes them excellent for development and poor for steady production load — the table shows their shape, not that caveat, so keep it in mind when the smallest match is one of them.
• Cloud SQL entries here are common custom shapes, not an exhaustive catalogue, because Cloud SQL lets you request nearly any combination of vCPU and memory. Treat that column as representative.
• These parameter values are the defaults an instance ships with, not limits. All three clouds let you override them through a parameter group or flag, and the connection formulas in particular are only defaults — see the max connections calculator for what changing them costs you.

Common questions

Why does max_connections change when I switch engines?

Because each engine has its own divisor in the provider's formula. On AWS, PostgreSQL divides available memory by about 9.5 MB per connection while MySQL divides by about 12.6 MB, so the same instance yields fewer MySQL connections. MariaDB from 10.5 uses a different divisor again.

Is more memory per vCPU always better for a database?

Usually, up to the point where your working set fits in memory. Once the data a query touches is cached, adding memory stops buying speed and only buys connection headroom. If your dataset is small and your queries are CPU-heavy — lots of sorting, aggregation or JSON processing — a lower ratio with more cores can be the better instance.

Can I change these parameter values after launching?

Yes, through a parameter group on RDS, server parameters on Azure, or database flags on Cloud SQL. Some take effect immediately and some need a reboot — shared_buffers and innodb_buffer_pool_size allocate at startup, so they are in the reboot category. The defaults shown here are sensible starting points and worth a reason before overriding.

Sources

• Amazon RDS — DB instance classes
• Azure Database for PostgreSQL — limits
• Cloud SQL for PostgreSQL — flags