Skip to content

Databases Updated 2026-05-29

Database auto-configuration

How Stack Harbor PaaS sizes MySQL, MariaDB, Percona, and PostgreSQL engine parameters against container resource limits — and how to override.

Stack Harbor PaaS sizes a small set of engine parameters against the container’s allocated resources, so MySQL, MariaDB, Percona, and PostgreSQL do not run on out-of-the-box defaults that ignore how much RAM and CPU the container actually has.

This page covers which settings are auto-configured, when they are recalculated, and how to disable auto-configuration when you want to manage them by hand.

MySQL / MariaDB / Percona

The platform manages four settings in /etc/my.cnf, sized against the container’s resource limit:

  • key_buffer_size
  • table_open_cache
  • myisam_sort_buffer_size
  • innodb_buffer_pool_size

Starting from MySQL 5.7, MySQL 8.0, Percona at the matching version, and MariaDB 10.x, two more parameters are added:

  • innodb_buffer_pool_instances — note: deprecated in MariaDB starting at 10.6.x (the value is always 1 pool instance from that version on).
  • innodb_buffer_pool_chunk_size

Every vertical-resize event re-runs the sizing pass against the new container limit. You do not need to restart the database after a resize for the new sizing to apply — the platform handles it.

PostgreSQL

For PostgreSQL containers, two parameters in /var/lib/pgsql/data/postgresql.conf are managed:

  • shared_buffers — a fraction of total RAM. A quarter of RAM when the container has eight or more cloudlets, a seventh otherwise; the floor is 128 KB.
  • max_stack_depth — ulimit -s minus 1024, in MB.

These are recalculated on resize, same as the MySQL-family settings.

Disabling auto-configuration

When you want to manage these settings by hand, you have two options.

The current containers

Set the JELASTIC_AUTOCONFIG environment variable to false, disable, or 0. The platform will stop touching the managed settings, and your edits to /etc/my.cnf (or postgresql.conf) will survive future updates.

Legacy containers

Older containers use a marker line at the top of the config file:

#Jelastic autoconfiguration mark.

Remove that line and your manual edits below will be preserved. Leave it in place and the platform will overwrite the managed settings on the next update pass.

Overriding without disabling autoconfig

For MySQL-family containers, a cleaner alternative is to drop overrides into /etc/mysql/conf.d/my_custom.cnf. Settings in this file take precedence over /etc/my.cnf, including over the auto-configured values, and the platform does not manage my_custom.cnf. You keep the platform-managed defaults for everything else.

PostgreSQL does not have a built-in conf.d mechanism in the same place — manage postgresql.conf directly after removing the autoconfig mark, or use ALTER SYSTEM SQL to write to postgresql.auto.conf.

When to disable autoconfig

Most workloads do better with the auto-configured values than with hand-rolled defaults — the platform’s sizing scales with container resource limits, so a vertical resize automatically updates buffer pool sizes too.

Disable autoconfig when:

  • A query workload needs an innodb_buffer_pool_size larger or smaller than the platform default.
  • You’re benchmarking and want strict control of buffer sizing.
  • A specific extension or replication mode requires a managed setting at a non-default value.

In all other cases, leaving autoconfig on means a resize Just Works.

See also