{"id":33603,"date":"2024-06-12T11:25:45","date_gmt":"2024-06-12T09:25:45","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=33603"},"modified":"2024-06-12T11:25:49","modified_gmt":"2024-06-12T09:25:49","slug":"cloudnativepg-scaling-up-and-down","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/","title":{"rendered":"CloudNativePG – Scaling up and down"},"content":{"rendered":"\n

By now, if you followed the previous posts (here<\/a>, here<\/a>, here<\/a>, here<\/a> and here<\/a>), we know quite a bit about how to use CloudNativePG<\/a> to deploy a PostgreSQL cluster and how to get detailed information about the deployment. What we’ll look at in this post is how you can leverage this deployment to scale the cluster up and down. This might be important if you have changing workloads throughout the day or the week and your application is able to distribute read only workloads across the PostgreSQL replicas.<\/p>\n\n\n\n

When we look at what we have now, we do see this:<\/p>\n\n\n

\nminicube@micro-minicube:~> kubectl-cnpg status my-pg-cluster\nCluster Summary\nName:                my-pg-cluster\nNamespace:           default\nSystem ID:           7378131726640287762\nPostgreSQL Image:    ghcr.io\/cloudnative-pg\/postgresql:16.2\nPrimary instance:    my-pg-cluster-1\nPrimary start time:  2024-06-08 13:59:26 +0000 UTC (uptime 88h35m7s)\nStatus:              Cluster in healthy state \nInstances:           3\nReady instances:     3\nCurrent Write LSN:   0\/26000000 (Timeline: 1 - WAL File: 000000010000000000000012)\n\nCertificates Status\nCertificate Name           Expiration Date                Days Left Until Expiration\n----------------           ---------------                --------------------------\nmy-pg-cluster-ca           2024-09-06 13:54:17 +0000 UTC  86.31\nmy-pg-cluster-replication  2024-09-06 13:54:17 +0000 UTC  86.31\nmy-pg-cluster-server       2024-09-06 13:54:17 +0000 UTC  86.31\n\nContinuous Backup status\nNot configured\n\nPhysical backups\nNo running physical backups found\n\nStreaming Replication status\nReplication Slots Enabled\nName             Sent LSN    Write LSN   Flush LSN   Replay LSN  Write Lag  Flush Lag  Replay Lag  State      Sync State  Sync Priority  Replication Slot\n----             --------    ---------   ---------   ----------  ---------  ---------  ----------  -----      ----------  -------------  ----------------\nmy-pg-cluster-2  0\/26000000  0\/26000000  0\/26000000  0\/26000000  00:00:00   00:00:00   00:00:00    streaming  async       0              active\nmy-pg-cluster-3  0\/26000000  0\/26000000  0\/26000000  0\/26000000  00:00:00   00:00:00   00:00:00    streaming  async       0              active\n\nUnmanaged Replication Slot Status\nNo unmanaged replication slots found\n\nManaged roles status\nNo roles managed\n\nTablespaces status\nNo managed tablespaces\n\nPod Disruption Budgets status\nName                   Role     Expected Pods  Current Healthy  Minimum Desired Healthy  Disruptions Allowed\n----                   ----     -------------  ---------------  -----------------------  -------------------\nmy-pg-cluster          replica  2              2                1                        1\nmy-pg-cluster-primary  primary  1              1                1                        0\n\nInstances status\nName             Database Size  Current LSN  Replication role  Status  QoS         Manager Version  Node\n----             -------------  -----------  ----------------  ------  ---         ---------------  ----\nmy-pg-cluster-1  37 MB          0\/26000000   Primary           OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-2  37 MB          0\/26000000   Standby (async)   OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-3  37 MB          0\/26000000   Standby (async)   OK      BestEffort  1.23.1           minikube\n\n<\/pre><\/div>\n\n\n
We have a primary instance running in pod my-pg-cluster-1, and we have two replicas in asynchronous mode running in pods my-pg-cluster-2 and my-pg-cluster-3. Let’s assume we have an increasing workload and we want to have two more replicas. There are two ways in which you can do this. The first one is to change the configuration of the cluster in the yaml and then re-apply the configuration. This is the configuration as it is now:<\/p>\n\n\n
\napiVersion: postgresql.cnpg.io\/v1\nkind: Cluster\nmetadata:\n  name: my-pg-cluster\nspec:\n  instances: 3\n\n  bootstrap:\n    initdb:\n      database: db1\n      owner: db1\n      dataChecksums: true\n      walSegmentSize: 32\n      localeCollate: 'en_US.utf8'\n      localeCType: 'en_US.utf8'\n      postInitSQL:\n      - create user db2\n      - create database db2 with owner = db2\n\n  postgresql:\n    parameters:\n      work_mem: "12MB"\n      pg_stat_statements.max: "2500"\n    pg_hba:\n      - host all all 192.168.122.0\/24 scram-sha-256\n\n  storage:\n    size: 1Gi\n<\/pre><\/div>\n\n\n
All we need to do is to change the number of instances we want to have. With the current value of three, we get one primary and two replicas. If we want to have two more replicas, change this to five and re-apply:<\/p>\n\n\n
\nminicube@micro-minicube:~> grep instances pg.yaml \n  instances: 5\nminicube@micro-minicube:~> kubectl apply -f pg.yaml\ncluster.postgresql.cnpg.io\/my-pg-cluster configured\n<\/pre><\/div>\n\n\n
By monitoring the pods you can follow the progress of bringing up two new pods and attaching the replicas to the current cluster:<\/p>\n\n\n
\nminicube@micro-minicube:~> kubectl get pods\nNAME                         READY   STATUS            RESTARTS      AGE\nmy-pg-cluster-1              1\/1     Running           1 (32m ago)   2d1h\nmy-pg-cluster-2              1\/1     Running           1 (32m ago)   2d\nmy-pg-cluster-3              1\/1     Running           1 (32m ago)   2d\nmy-pg-cluster-4              0\/1     PodInitializing   0             3s\nmy-pg-cluster-4-join-kqgwp   0\/1     Completed         0             11s\nminicube@micro-minicube:~> kubectl get pods\nNAME              READY   STATUS    RESTARTS      AGE\nmy-pg-cluster-1   1\/1     Running   1 (33m ago)   2d1h\nmy-pg-cluster-2   1\/1     Running   1 (33m ago)   2d\nmy-pg-cluster-3   1\/1     Running   1 (33m ago)   2d\nmy-pg-cluster-4   1\/1     Running   0             42s\nmy-pg-cluster-5   1\/1     Running   0             19s\n<\/pre><\/div>\n\n\n
Now we see five pods, as requested, and looking at the PostgreSQL streaming replication configuration confirms that we now have four replicas:<\/p>\n\n\n
\nminicube@micro-minicube:~> kubectl-cnpg status my-pg-cluster\nCluster Summary\nName:                my-pg-cluster\nNamespace:           default\nSystem ID:           7378131726640287762\nPostgreSQL Image:    ghcr.io\/cloudnative-pg\/postgresql:16.2\nPrimary instance:    my-pg-cluster-1\nPrimary start time:  2024-06-08 13:59:26 +0000 UTC (uptime 88h43m54s)\nStatus:              Cluster in healthy state \nInstances:           5\nReady instances:     5\nCurrent Write LSN:   0\/2C000060 (Timeline: 1 - WAL File: 000000010000000000000016)\n\nCertificates Status\nCertificate Name           Expiration Date                Days Left Until Expiration\n----------------           ---------------                --------------------------\nmy-pg-cluster-ca           2024-09-06 13:54:17 +0000 UTC  86.30\nmy-pg-cluster-replication  2024-09-06 13:54:17 +0000 UTC  86.30\nmy-pg-cluster-server       2024-09-06 13:54:17 +0000 UTC  86.30\n\nContinuous Backup status\nNot configured\n\nPhysical backups\nNo running physical backups found\n\nStreaming Replication status\nReplication Slots Enabled\nName             Sent LSN    Write LSN   Flush LSN   Replay LSN  Write Lag  Flush Lag  Replay Lag  State      Sync State  Sync Priority  Replication Slot\n----             --------    ---------   ---------   ----------  ---------  ---------  ----------  -----      ----------  -------------  ----------------\nmy-pg-cluster-2  0\/2C000060  0\/2C000060  0\/2C000060  0\/2C000060  00:00:00   00:00:00   00:00:00    streaming  async       0              active\nmy-pg-cluster-3  0\/2C000060  0\/2C000060  0\/2C000060  0\/2C000060  00:00:00   00:00:00   00:00:00    streaming  async       0              active\nmy-pg-cluster-4  0\/2C000060  0\/2C000060  0\/2C000060  0\/2C000060  00:00:00   00:00:00   00:00:00    streaming  async       0              active\nmy-pg-cluster-5  0\/2C000060  0\/2C000060  0\/2C000060  0\/2C000060  00:00:00   00:00:00   00:00:00    streaming  async       0              active\n\nUnmanaged Replication Slot Status\nNo unmanaged replication slots found\n\nManaged roles status\nNo roles managed\n\nTablespaces status\nNo managed tablespaces\n\nPod Disruption Budgets status\nName                   Role     Expected Pods  Current Healthy  Minimum Desired Healthy  Disruptions Allowed\n----                   ----     -------------  ---------------  -----------------------  -------------------\nmy-pg-cluster          replica  4              4                3                        1\nmy-pg-cluster-primary  primary  1              1                1                        0\n\nInstances status\nName             Database Size  Current LSN  Replication role  Status  QoS         Manager Version  Node\n----             -------------  -----------  ----------------  ------  ---         ---------------  ----\nmy-pg-cluster-1  37 MB          0\/2C000060   Primary           OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-2  37 MB          0\/2C000060   Standby (async)   OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-3  37 MB          0\/2C000060   Standby (async)   OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-4  37 MB          0\/2C000060   Standby (async)   OK      BestEffort  1.23.1           minikube\nmy-pg-cluster-5  37 MB          0\/2C000060   Standby (async)   OK      BestEffort  1.23.1           minikube\n<\/pre><\/div>\n\n\n
If you want to scale this down again (maybe because the workload decreased), you can do that in the same way by reducing the number of instances from five to three in the cluster definition, or by directly scaling the cluster down with kubectl:<\/p>\n\n\n
\nminicube@micro-minicube:~> kubectl scale --replicas=2 -f pg.yaml \ncluster.postgresql.cnpg.io\/my-pg-cluster scaled\n<\/pre><\/div>\n\n\n
Attention: Replicas in this context does not mean streaming replication replicas. It means replicas in the context of Kubernetes, so if you do it like above, the result will be one primary and one replica:<\/p>\n\n\n
\nminicube@micro-minicube:~> kubectl get pods\nNAME              READY   STATUS    RESTARTS      AGE\nmy-pg-cluster-1   1\/1     Running   1 (39m ago)   2d1h\nmy-pg-cluster-2   1\/1     Running   1 (39m ago)   2d1h\n<\/pre><\/div>\n\n\n
What you probably really want is this (to get back to the initial state of the cluster):<\/p>\n\n\n
\nminicube@micro-minicube:~> kubectl scale --replicas=3 -f pg.yaml \ncluster.postgresql.cnpg.io\/my-pg-cluster scaled\nminicube@micro-minicube:~> kubectl get pods\nNAME                         READY   STATUS    RESTARTS      AGE\nmy-pg-cluster-1              1\/1     Running   1 (41m ago)   2d1h\nmy-pg-cluster-2              1\/1     Running   1 (41m ago)   2d1h\nmy-pg-cluster-6-join-747nx   0\/1     Pending   0             1s\nminicube@micro-minicube:~> kubectl get pods\nNAME                         READY   STATUS    RESTARTS      AGE\nmy-pg-cluster-1              1\/1     Running   1 (41m ago)   2d1h\nmy-pg-cluster-2              1\/1     Running   1 (41m ago)   2d1h\nmy-pg-cluster-6-join-747nx   1\/1     Running   0             5s\nminicube@micro-minicube:~> kubectl get pods\nNAME                         READY   STATUS      RESTARTS      AGE\nmy-pg-cluster-1              1\/1     Running     1 (42m ago)   2d1h\nmy-pg-cluster-2              1\/1     Running     1 (42m ago)   2d1h\nmy-pg-cluster-6              0\/1     Running     0             5s\nmy-pg-cluster-6-join-747nx   0\/1     Completed   0             14s\n...\nminicube@micro-minicube:~> kubectl get pods\nNAME              READY   STATUS    RESTARTS      AGE\nmy-pg-cluster-1   1\/1     Running   1 (42m ago)   2d1h\nmy-pg-cluster-2   1\/1     Running   1 (42m ago)   2d1h\nmy-pg-cluster-6   1\/1     Running   0             16s\n<\/pre><\/div>\n\n\n
What you shouldn’t do is to mix both ways of scaling, for one reason: If you scale up or down by using “kubectl scale”, this will not modify your cluster configuration file. There we still have five instances:<\/p>\n\n\n
\nminicube@micro-minicube:~> grep instances pg.yaml \n  instances: 5\n<\/pre><\/div>\n\n\n
Our recommendation is, to do this only by modifying the configuration and re-apply afterwards. This ensures, that you always have the “reality” in the configuration file, and not a mix of live state and desired state.<\/p>\n\n\n\n
In the next we’ll look into storage, because you want your databases to be persistent and fast.<\/p>\n","protected":false},"excerpt":{"rendered":"
By now, if you followed the previous posts (here, here, here, here and here), we know quite a bit about how to use CloudNativePG to deploy a PostgreSQL cluster and how to get detailed information about the deployment. What we’ll look at in this post is how you can leverage this deployment to scale the […]<\/p>\n","protected":false},"author":29,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[955,229,198,1320],"tags":[77],"type_dbi":[],"class_list":["post-33603","post","type-post","status-publish","format-standard","hentry","category-cloud","category-database-administration-monitoring","category-database-management","category-devops","tag-postgresql"],"acf":[],"yoast_head":"\nCloudNativePG - Scaling up and down - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"CloudNativePG - Scaling up and down\" \/>\n<meta property=\"og:description\" content=\"By now, if you followed the previous posts (here, here, here, here and here), we know quite a bit about how to use CloudNativePG to deploy a PostgreSQL cluster and how to get detailed information about the deployment. What we’ll look at in this post is how you can leverage this deployment to scale the […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2024-06-12T09:25:45+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-06-12T09:25:49+00:00\" \/>\n<meta name=\"author\" content=\"Daniel Westermann\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@westermanndanie\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Westermann\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"2 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/\"},\"author\":{\"name\":\"Daniel Westermann\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"headline\":\"CloudNativePG – Scaling up and down\",\"datePublished\":\"2024-06-12T09:25:45+00:00\",\"dateModified\":\"2024-06-12T09:25:49+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/\"},\"wordCount\":460,\"commentCount\":0,\"keywords\":[\"PostgreSQL\"],\"articleSection\":[\"Cloud\",\"Database Administration & Monitoring\",\"Database management\",\"DevOps\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/\",\"name\":\"CloudNativePG - Scaling up and down - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2024-06-12T09:25:45+00:00\",\"dateModified\":\"2024-06-12T09:25:49+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/cloudnativepg-scaling-up-and-down\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CloudNativePG – Scaling up and down\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\",\"name\":\"Daniel Westermann\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"caption\":\"Daniel Westermann\"},\"description\":\"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\\\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.\",\"sameAs\":[\"https:\\\/\\\/x.com\\\/westermanndanie\"],\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/daniel-westermann\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"CloudNativePG - Scaling up and down - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/","og_locale":"en_US","og_type":"article","og_title":"CloudNativePG - Scaling up and down","og_description":"By now, if you followed the previous posts (here, here, here, here and here), we know quite a bit about how to use CloudNativePG to deploy a PostgreSQL cluster and how to get detailed information about the deployment. What we’ll look at in this post is how you can leverage this deployment to scale the […]","og_url":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/","og_site_name":"dbi Blog","article_published_time":"2024-06-12T09:25:45+00:00","article_modified_time":"2024-06-12T09:25:49+00:00","author":"Daniel Westermann","twitter_card":"summary_large_image","twitter_creator":"@westermanndanie","twitter_misc":{"Written by":"Daniel Westermann","Est. reading time":"2 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/"},"author":{"name":"Daniel Westermann","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"headline":"CloudNativePG – Scaling up and down","datePublished":"2024-06-12T09:25:45+00:00","dateModified":"2024-06-12T09:25:49+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/"},"wordCount":460,"commentCount":0,"keywords":["PostgreSQL"],"articleSection":["Cloud","Database Administration & Monitoring","Database management","DevOps"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/","url":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/","name":"CloudNativePG - Scaling up and down - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2024-06-12T09:25:45+00:00","dateModified":"2024-06-12T09:25:49+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/cloudnativepg-scaling-up-and-down\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"CloudNativePG – Scaling up and down"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66","name":"Daniel Westermann","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","caption":"Daniel Westermann"},"description":"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.","sameAs":["https:\/\/x.com\/westermanndanie"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33603","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=33603"}],"version-history":[{"count":11,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33603\/revisions"}],"predecessor-version":[{"id":33614,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33603\/revisions\/33614"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=33603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=33603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=33603"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=33603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}