diff --git a/addons-cluster/postgresql/templates/_helpers.tpl b/addons-cluster/postgresql/templates/_helpers.tpl
index eecb3821e..5c7d4066c 100644
--- a/addons-cluster/postgresql/templates/_helpers.tpl
+++ b/addons-cluster/postgresql/templates/_helpers.tpl
@@ -19,14 +19,14 @@ Define postgresql ComponentSpec with ComponentDefinition.
   topology: {{ .Values.mode }}
   componentSpecs:
     - name: {{ include "postgresql-cluster.component-name" . }}
+      serviceVersion: {{ .Values.version }}
       labels:
         {{- include "postgresql-cluster.patroni-scope-label" . | indent 8 }}
-      {{- include "postgresql-cluster.replicaCount" . | indent 6 }}
-      serviceAccountName: {{ include "kblib.serviceAccountName" . }}
       {{- include "kblib.componentMonitor" . | indent 6 }}
+      {{- include "postgresql-cluster.replicaCount" . | indent 6 }}
       {{- include "kblib.componentResources" . | indent 6 }}
       {{- include "kblib.componentStorages" . | indent 6 }}
-      {{- if .Values.etcd.proxyEnabled }}
+      {{- if .Values.etcd.enabled }}
       serviceRefs:
       {{ include "postgresql-cluster.serviceRef" . | indent 6 }}
       {{- end }}
diff --git a/addons-cluster/postgresql/templates/etcd-service-descriptor-example.yaml b/addons-cluster/postgresql/templates/etcd-service-descriptor-example.yaml
index 357b7df10..2d7452fee 100644
--- a/addons-cluster/postgresql/templates/etcd-service-descriptor-example.yaml
+++ b/addons-cluster/postgresql/templates/etcd-service-descriptor-example.yaml
@@ -1,3 +1,4 @@
+{{- if and .Values.etcd.enabled (eq .Values.etcd.meta.mode "serviceref") }}
 apiVersion: apps.kubeblocks.io/v1
 kind: ServiceDescriptor
 metadata:
@@ -8,4 +9,4 @@ spec:
   serviceVersion: 3.5.6
   endpoint:
     value: "etcd-cluster-etcd.default.svc.cluster.local:2379"  # etcd service endpoint
-    
+{{- end }}
diff --git a/addons-cluster/postgresql/values.yaml b/addons-cluster/postgresql/values.yaml
index 3737622d8..dd36588b7 100644
--- a/addons-cluster/postgresql/values.yaml
+++ b/addons-cluster/postgresql/values.yaml
@@ -37,20 +37,16 @@ requests:
 ##
 storage: 20
 
-## @param monitor sidecar
-sidecars:
- - exporter
-  
 etcd:
-  proxyEnabled: false
+  enabled: false
   meta:
     mode: serviceref # optional: incluster, serviceref
     serviceRef:
-      namespace: 
-      cluster: 
-        name: 
-        component: 
-        service: 
-        port: 
+      namespace:
+      cluster:
+        name:
+        component:
+        service:
+        port:
         credential:
       serviceDescriptor: postgres-etcd-descriptor # example: postgres-etcd-descriptor
diff --git a/addons/postgresql/templates/clusterdefinition.yaml b/addons/postgresql/templates/clusterdefinition.yaml
index 1723026f8..0ef920714 100644
--- a/addons/postgresql/templates/clusterdefinition.yaml
+++ b/addons/postgresql/templates/clusterdefinition.yaml
@@ -6,12 +6,8 @@ metadata:
     {{- include "postgresql.labels" . | nindent 4 }}
 spec:
   topologies:
-    - name: standalone
-      components:
-        - name: postgresql
-          compDef: {{ include "postgresql.componentDefNamePrefix" . }}
-      default: true
     - name: replication
       components:
         - name: postgresql
           compDef: {{ include "postgresql.componentDefNamePrefix" . }}
+      default: true
diff --git a/examples/apecloud-mysql/cluster.yaml b/examples/apecloud-mysql/cluster.yaml
index 4ebe2d78e..8882bcff8 100644
--- a/examples/apecloud-mysql/cluster.yaml
+++ b/examples/apecloud-mysql/cluster.yaml
@@ -3,7 +3,7 @@ kind: Cluster
 metadata:
   name: acmysql-cluster
   namespace: default
-  labels: 
+  labels:
     auditLogEnabled: "false"
 spec:
   # Specifies the behavior when a Cluster is deleted.
diff --git a/examples/postgresql/README.md b/examples/postgresql/README.md
index d7da9e653..540b43234 100644
--- a/examples/postgresql/README.md
+++ b/examples/postgresql/README.md
@@ -6,9 +6,10 @@ PostgreSQL (Postgres) is an open source object-relational database known for rel
 
 This example assumes that you have a Kubernetes cluster installed and running, and that you have installed the kubectl command line tool and helm somewhere in your path. Please see the [getting started](https://kubernetes.io/docs/setup/)  and [Installing Helm](https://helm.sh/docs/intro/install/) for installation instructions for your platform.
 
-Also, this example requires kubeblocks installed and running. Here is the steps to install kubeblocks, please replace "`$kb_version`" with the version you want to use.
+Also, this example requires KubeBlocks installed and running. Here is the steps to install kubeblocks, please replace "`$kb_version`" with the version you want to use.
+
 ```bash
-# Add Helm repo 
+# Add Helm repo
 helm repo add kubeblocks https://apecloud.github.io/helm-charts
 # If github is not accessible or very slow for you, please use following repo instead
 helm repo add kubeblocks https://jihulab.com/api/v4/projects/85949/packages/helm/stable
@@ -29,132 +30,536 @@ kubectl create -f https://jihulab.com/api/v4/projects/98723/packages/generic/kub
 # Install KubeBlocks
 helm install kubeblocks kubeblocks/kubeblocks --namespace kb-system --create-namespace --version="$kb_version"
 ```
- 
 
 ## Examples
 
-### [Create](cluster.yaml) 
-Create a postgresql cluster with specified cluster definition 
+### [Create](cluster.yaml)
+
+Create a postgresql cluster with one primary and one secondary instance:
+
 ```bash
 kubectl apply -f examples/postgresql/cluster.yaml
 ```
-Starting from kubeblocks 0.9.0, we introduced a more flexible cluster creation method based on components, allowing customization of cluster topology, functionalities and scale according to specific requirements.
+
+And you will see the postgresql cluster status goes `Running` after a while:
+
 ```bash
-kubectl apply -f examples/postgresql/cluster-cmpd.yaml
+kubectl get cluster pg-cluster
 ```
-### [Horizontal scaling](horizontalscale.yaml)
-Horizontal scaling out or in specified components replicas in the cluster
+
+and two pods are `Running` with roles `primary` and `secondary` separately. To check the roles of the pods, you can use following command:
+
 ```bash
-kubectl apply -f examples/postgresql/horizontalscale.yaml
+# replace `pg-cluster` with your cluster name
+kubectl get po -l  app.kubernetes.io/instance=pg-cluster -L kubeblocks.io/role -n default
+# or login to the pod and use `patronictl` to check the roles:
+kubectl exec -it pg-cluster-postgresql-0 -n default -- patronictl list
+```
+
+If you want to create a postgresql cluster of specified version, just modify the `spec.componentSpecs.serviceVersion` field in the yaml file before applying it:
+
+```yaml
+spec:
+  terminationPolicy: Delete
+  clusterDef: postgresql
+  topology: replication
+  componentSpecs:
+    - name: postgresql
+      # ServiceVersion specifies the version of the Service expected to be
+      # provisioned by this Component.
+      # Valid options are: [12.14.0,12.14.1,12.15.0,14.7.2,14.8.0,15.7.0,16.4.0]
+      serviceVersion: "14.7.2"
+```
+
+The list of supported versions can be found by following command:
+
+```bash
+kubectl get cmpv postgresql
+```
+
+And the expected output is like:
+
+```bash
+NAME         VERSIONS                                              STATUS      AGE
+postgresql   12.14.0,12.14.1,12.15.0,14.7.2,14.8.0,15.7.0,16.4.0   Available   Xd
+```
+
+### Horizontal scaling
+
+#### [Scale-out](scale-out.yaml)
+
+Horizontal scaling out postgresql cluster by adding ONE more replica:
+
+```bash
+kubectl apply -f examples/postgresql/scale-out.yaml
+```
+
+After applying the operation, you will see a new pod created and the postgresql cluster status goes from `Updating` to `Running`, and the newly created pod has a new role `secondary`.
+
+And you can check the progress of the scaling operation with following command:
+
+```bash
+kubectl describe ops pg-scale-in
+```
+
+#### [Scale-in](scale-in.yaml)
+
+Horizontal scaling in postgresql cluster by deleting ONE replica:
+
+```bash
+kubectl apply -f examples/postgresql/scale-in.yaml
+```
+
+Besides, you can also use `kubectl edit` to scale the cluster:
+
+```bash
+kubectl edit cluster pg-cluster
+```
+
+And modify the `replicas` field in the `spec.componentSpecs.replicas` section to the desired number.
+
+```yaml
+spec:
+  componentSpecs:
+    - name: postgresql
+      serviceVersion: "14.7.2"
+      disableExporter: true
+      labels:
+        apps.kubeblocks.postgres.patroni/scope: pg-cluster-postgresql
+      # Update `replicas` to 1 for scaling in, and to 3 for scaling out
+      replicas: 2
 ```
 
 ### [Vertical scaling](verticalscale.yaml)
-Vertical scaling up or down specified components requests and limits cpu or memory resource in the cluster
+
+Vertical scaling involves increasing or decreasing resources to an existing database clsuter.
+Resources that can be scaled include:, CPU cores/processing power and Memory (RAM).
+
+To vertical scaling up or down specified component, you can apply the following yaml file:
+
 ```bash
 kubectl apply -f examples/postgresql/verticalscale.yaml
 ```
 
+You will observe that the `secondary` pod is recreated first, followed by the `primary` pod, to ensure the availability of the cluster.
+
+Optionally, you can use `kubectl edit` to scale the cluster, and udpate `spec.componentSpecs.resources` field to the desired resources.
+
+```yaml
+spec:
+  componentSpecs:
+    - name: postgresql
+      replicas: 2
+      # Update the resources to your need.
+      resources:
+        requests:
+          cpu: "1"
+          memory: "2Gi"
+        limits:
+          cpu: "2"
+          memory: "4Gi"
+```
+
 ### [Expand volume](volumeexpand.yaml)
-Increase size of volume storage with the specified components in the cluster
+
+Volume expansion is the ability to increase the size of a Persistent Volume Claim (PVC) after it's created.
+
+> [!NOTE]
+> Make sure the storage class you use supports volume expansion.
+> You can check the storage class with following command:
+>
+> ```bash
+> kubectl get sc
+> ```
+>
+> If the `ALLOWVOLUMEEXPANSION` column is `true`, the storage class supports volume expansion.
+
+To increase size of volume storage with the specified components in the cluster
+
 ```bash
 kubectl apply -f examples/postgresql/volumeexpand.yaml
 ```
 
+After the operation, you will see the volume size of the specified component is increased to `30Gi` in this case.
+You can check the volume size with following command:
+
+```bash
+kubectl get pvc -l app.kubernetes.io/instance=pg-cluster -n default
+```
+
+You can also use `kubectl edit` to expand the volume:
+
+```bash
+kubectl edit cluster pg-cluster
+```
+
+And modify the `spec.componentSpecs.volumeClaimTemplates.spec.resources.requests.storage` field to the desired size.
+
+```yaml
+spec:
+  componentSpecs:
+    - name: postgresql
+      volumeClaimTemplates:
+        - metadata:
+            name: data
+          spec:
+            accessModes:
+              - ReadWriteOnce
+            resources:
+              requests:
+                # update the storage size to your need
+                storage: 30Gi
+```
+
 ### [Restart](restart.yaml)
-Restart the specified components in the cluster
+
+Restart the specified components in the cluster, and instances will be recreated on after another to ensure the availability of the cluster
+
 ```bash
 kubectl apply -f examples/postgresql/restart.yaml
 ```
 
 ### [Stop](stop.yaml)
-Stop the cluster and release all the pods of the cluster, but the storage will be reserved
+
+Stop the cluster will release all the pods of the cluster, but the storage will be retained. It is useful when you want to save the cost of the cluster.
+
 ```bash
 kubectl apply -f examples/postgresql/stop.yaml
 ```
 
+You can also use `kubectl edit` to stop the cluster by setting the `spec.componentSpecs.stop` field to `true`.
+
+```yaml
+spec:
+  componentSpecs:
+    - name: postgresql
+      stop: true  # set stop `true` to stop the component
+      replicas: 2
+```
+
 ### [Start](start.yaml)
+
 Start the stopped cluster
+
 ```bash
 kubectl apply -f examples/postgresql/start.yaml
 ```
 
+Similary, you can use `kubectl edit` to start the cluster:
+
+```bash
+kubectl edit cluster pg-cluster
+```
+
+And modify the `spec.componentSpecs.stop` field to `false` or remove the `spec.componentSpecs.stop` field.
+
+```yaml
+spec:
+  componentSpecs:
+    - name: postgresql
+      stop: false  # set to `false` (or remove this field) to start the component
+      replicas: 2
+```
+
 ### [Switchover](switchover.yaml)
-Switchover a non-primary or non-leader instance as the new primary or leader of the cluster
+
+A switchover in database clusters is a planned operation that transfers the primary (leader) role from one database instance to another. The goal of a switchover is to ensure that the database cluster remains available and operational during the transition. To perform a switchover operation, you can apply the following yaml file:
+
 ```bash
 kubectl apply -f examples/postgresql/switchover.yaml
 ```
 
+<details>
+
+By applying this yaml file, KubeBlocks will perform a switchover operation defined in postgresql's component definition, and you can checkout the details in `componentdefinition.spec.lifecycleActions.switchover`.
+
+You may get the switchover operation details with following command:
+
+```bash
+kubectl get cluster pg-cluster -ojson | jq '.spec.componentSpecs[0].componentDef' | xargs kubectl get cmpd -ojson | jq '.spec.lifecycleActions.switchover'
+```
+
+</details>
+
+
 ### [Switchover-specified-instance](switchover-specified-instance.yaml)
+
 Switchover a specified instance as the new primary or leader of the cluster
+
 ```bash
 kubectl apply -f examples/postgresql/switchover-specified-instance.yaml
 ```
 
-### [Configure](configure.yaml)
-Configure parameters with the specified components in the cluster
+You may need to modify the `opsrequest.spec.switchover.instanceName` field to your desired `secondary` instance name.
+
+Once this `opsrequest` is completed, you can check the status of the switchover operation and the roles of the pods to verify the switchover operation.
+
+### [Reconfigure](configure.yaml)
+
+A database reconfiguration is the process of modifying database parameters, settings, or configurations to improve performance, security, or availability. The reconfiguration can be either:
+
+- Dynamic: Applied without restart
+- Static: Requires database restart
+
+Reconfigure parameters with the specified components in the cluster
+
 ```bash
 kubectl apply -f examples/postgresql/configure.yaml
 ```
 
+This example will change the `max_connections` to `200`.
+> `max_connections` indicates maximum number of client connections allowed. It is a dynamic parameter, so the change will take effect without restarting the database.
+
+<details>
+
+To check the full list of parameters that can be reconfigured, you can use following command:
+
+```bash
+kbcli cluster explain-config pg-cluster # kbcli is a command line tool to interact with KubeBlocks
+```
+</details>
+
 ### [BackupRepo](backuprepo.yaml)
-BackupRepo is the storage repository for backup data, using the full backup and restore function of KubeBlocks relies on BackupRepo
+
+BackupRepo is the storage repository for backup data. Before creating a BackupRepo, you need to create a secret to save the access key of the backup repository
+
 ```bash
 # Create a secret to save the access key
-kubectl create secret generic <storage-provider>-credential-for-backuprepo\
+kubectl create secret generic <credential-for-backuprepo>\
   --from-literal=accessKeyId=<ACCESS KEY> \
   --from-literal=secretAccessKey=<SECRET KEY> \
-  -n kb-system 
-  
+  -n kb-system
+```
+
+Update `examples/postgresql/backuprepo.yaml` and set fields quoated with `<>` to your own settings and apply it.
+
+```bash
 kubectl apply -f examples/postgresql/backuprepo.yaml
 ```
 
-### [Backup](backup.yaml)
-Create pg-basebackup or volume-snapshot backup for the cluster
+After creating the BackupRepo, you should check the status of the BackupRepo, to make sure it is `Ready`.
+
 ```bash
-kubectl apply -f examples/postgresql/backup.yaml
+kubectl get backuprepo
 ```
-Create wal-g backup for the cluster
+
+And the expected output is like:
+
+```bash
+NAME     STATUS   STORAGEPROVIDER   ACCESSMETHOD   DEFAULT   AGE
+kb-oss   Ready    oss               Tool           true      Xd
+```
+
+### [Backup]
+
+KubeBlocks supports multiple backup methods for postgresql cluster, such as `pg-basebackup`, `volume-snapshot`, `wal-g`, etc.
+
+You may find the supported backup methods in the `BackupPolicy` of the cluster, e.g. `pg-cluster-postgresql-backup-policy` in this case, and find how these methods will be scheduled in the `BackupSchedule` of the cluster, e.g.. `pg-cluster-postgresql-backup-schedule` in this case.
+
+We will elaborate on the `pg-basebackup` and `wal-g` backup methods in the following sections to demonstrate how to create base backup and incremental backup for the cluster.
+
+#### [pg_basebackup]
+
+##### Base Backup(backup-pg-basebasekup.yaml)
+
+The method `pg-basebackup` uses `pg_basebackup`,  a PostgreSQL utility to create a base backup[^1]
+
+To create a base backup for the cluster, you can apply the following yaml file:
+
+```bash
+kubectl apply -f examples/postgresql/backup-pg-basebasekup.yaml
+```
+
+After the operation, you will see a `Backup` is created
+
+```bash
+kubectl get backup -l app.kubernetes.io/instance=pg-cluster
+```
+
+and the status of the backup goes from `Running` to `Completed` after a while. And the backup data will be pushed to your specified `BackupRepo`.
+
+Infomation, such as `path`, `timeRange` about the backup will be recoreded into the `Backup` resource.
+
+Alternatively, you can update the `BackupSchedule` to enable the method `pg-basebackup` to schedule base backup periodically, will be elaborated in the following section.
+
+#### Incremental Backup
+
+To enable incremental backup, you need to update `BackupSchedule` and enable the method `archive-wal`.
+
+```yaml
+apiVersion: dataprotection.kubeblocks.io/v1alpha1
+kind: BackupSchedule
+metadata:
+  name: pg-cluster-postgresql-backup-schedule
+  namespace: default
+spec:
+  backupPolicyName: pg-cluster-postgresql-backup-policy
+  schedules:
+  - backupMethod: pg-basebackup
+    # ┌───────────── minute (0-59)
+    # │ ┌───────────── hour (0-23)
+    # │ │ ┌───────────── day of month (1-31)
+    # │ │ │ ┌───────────── month (1-12)
+    # │ │ │ │ ┌───────────── day of week (0-6) (Sunday=0)
+    # │ │ │ │ │
+    # 0 18 * * *
+    # schedule this job every day at 6:00 PM (18:00).
+    cronExpression: 0 18 * * * # update the cronExpression to your need
+    enabled: false # set to `true` to schedule base backup periodically
+    retentionPeriod: 7d # set the retention period to your need
+  - backupMethod: archive-wal
+    cronExpression: '*/5 * * * *'
+    enabled: true  # set to `true` to enable incremental backup
+    retentionPeriod: 8d # set the retention period to your need
+```
+
+Once the `BackupSchedule` is updated, the incremental backup starts to work, and you can check the status of the backup with following command:
+
+```bash
+kubectl get backup -l app.kubernetes.io/instance=pg-cluster
+```
+
+And you will find one `Backup` named with suffix 'pg-cluster-postgresql-archive-wal' is created with the method `archive-wal`.
+
+It will run continuously until you disable the method `archive-wal` in the `BackupSchedule`. And the valid time range of the backup will be recorded in the `Backup` resource:
+
+```bash
+kubectl get backup -l app.kubernetes.io/instance=pg-cluster -l dataprotection.kubeblocks.io/backup-type=Continuous  -oyaml | yq '.items[].status.timeRange'
+```
+
+#### [wal-g]
+
+WAL-G is an archival restoration tool for PostgreSQL, MySQL/MariaDB, and MS SQL Server (beta for MongoDB and Redis).[^2]
+
+##### Base Backup(basebackup-wal-g.yaml)
+
+To create wal-g backup for the cluster, it is a multi-step process.
+
+1. configure WAL-G on all PostgreSQL pods
+
 ```bash
-# Step 1: you cannot do wal-g backup for a brand-new cluster, you need to insert some data before backup
-# step 2: config-wal-g backup to put the wal-g binary to postgresql pods and configure the archive_command
-# Note: if there is horizontal scaling out new pods after step 2, you need to do config-wal-g again
 kubectl apply -f examples/postgresql/config-wal-g.yaml
-# Step 3: do wal-g backup
+```
+
+1. set `archive_command` to `wal-g wal-push %p`
+
+```bash
+kubectl apply -f examples/postgresql/backup-wal-g.yaml
+```
+
+1. you cannot do wal-g backup for a brand-new cluster, you need to insert some data before backup
+
+1. create a backup
+
+```bash
 kubectl apply -f examples/postgresql/backup-wal-g.yaml
-# Step 4:log in to the cluster, and manually upload wal with following sql statement
-select pg_switch_wal();
 ```
 
+> [!Note]
+> if there is horizontal scaling out new pods after step 2, you need to do config-wal-g again
+
 ### [Restore](restore.yaml)
-Restore a new cluster from backup
+
+To restore a new cluster from a Backup:
+
+1. Get the list of accounts and their passwords from the backup:
+
 ```bash
-# Get backup connection password
-kubectl get backup pg-cluster-backup -ojsonpath='{.metadata.annotations.dataprotection\.kubeblocks\.io\/connection-password}' -n default
+kubectl get backup pg-cluster-pg-basebackup -ojsonpath='{.metadata.annotations.kubeblocks\.io/encrypted-system-accounts}'
+```
+
+1. Update `examples/postgresql/restore.yaml` and set fields quoated with `<>` to your own settings and apply it.
 
+```bash
 kubectl apply -f examples/postgresql/restore.yaml
 ```
 
 ### Expose
+
 Expose a cluster with a new endpoint
+
 #### [Enable](expose-enable.yaml)
+
 ```bash
 kubectl apply -f examples/postgresql/expose-enable.yaml
 ```
+
 #### [Disable](expose-disable.yaml)
+
 ```bash
 kubectl apply -f examples/postgresql/expose-disable.yaml
 ```
 
 ### [Upgrade](upgrade.yaml)
-Upgrade pg cluster to a newer version
+
+Upgrade postgresql cluster to another version
+
 ```bash
 kubectl apply -f examples/postgresql/upgrade.yaml
 ```
 
+In this example, the cluster will be upgraded to version `14.8.0`.
+You can check the available versions with following command:
+
+```bash
+kubectl get cmpv postgresql
+```
+
+And you can also use `kubectl edit` to upgrade the cluster:
+
+```bash
+kubectl edit cluster pg-cluster
+```
+
+And modify the `spec.componentSpecs.serviceVersion` field to the desired version.
+
+You are suggested to check the compatibility of versions before upgrading, using command:
+
+```bash
+kubectl get cmpv postgresql -ojson | jq '.spec.compatibilityRules'
+```
+<details>
+The expected output is like:
+```json
+[
+  {
+    "compDefs": [
+      "postgresql-12-"
+    ],
+    "releases": [
+      "12.14.0",
+      "12.14.1",
+      "12.15.0"
+    ]
+  },
+  {
+    "compDefs": [
+      "postgresql-14-"
+    ],
+    "releases": [
+      "14.7.2",
+      "14.8.0"
+    ]
+  }
+]
+```
+
+Releases are grouped by component definitions, and each group has a list of compatible releases.
+In this example, it shows you can upgrade from version `12.14.0` to `12.14.1` or `12.15.0`, and upgrade from `14.7.2` to `14.8.0`.
+But cannot upgrade from `12.14.0` to `14.8.0`.
+</details>
+
 ### Delete
+
 If you want to delete the cluster and all its resource, you can modify the termination policy and then delete the cluster
+
 ```bash
 kubectl patch cluster pg-cluster -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge"
 
 kubectl delete cluster pg-cluster
 ```
+
+## References
+
+[^1]: pg_basebackup, https://www.postgresql.org/docs/current/app-pgbasebackup.html
+[^2]: wal-g https://github.com/wal-g/wal-g
\ No newline at end of file
diff --git a/examples/postgresql/backup.yaml b/examples/postgresql/backup-pg-basebasekup.yaml
similarity index 96%
rename from examples/postgresql/backup.yaml
rename to examples/postgresql/backup-pg-basebasekup.yaml
index 770e511e0..3c8d566e0 100644
--- a/examples/postgresql/backup.yaml
+++ b/examples/postgresql/backup-pg-basebasekup.yaml
@@ -1,7 +1,7 @@
 apiVersion: dataprotection.kubeblocks.io/v1alpha1
 kind: Backup
 metadata:
-  name: pg-cluster-backup
+  name: pg-cluster-pg-basebackup
   namespace: default
 spec:
   # Specifies the backup method name that is defined in the backup policy.
diff --git a/examples/postgresql/backup-wal-g.yaml b/examples/postgresql/backup-wal-g.yaml
index b052086d5..a70e3c06b 100644
--- a/examples/postgresql/backup-wal-g.yaml
+++ b/examples/postgresql/backup-wal-g.yaml
@@ -1,7 +1,7 @@
 apiVersion: dataprotection.kubeblocks.io/v1alpha1
 kind: Backup
 metadata:
-  name: pg-cluster-backup
+  name: pg-cluster-wal-g
   namespace: default
 spec:
   # Specifies the backup method name that is defined in the backup policy.
diff --git a/examples/postgresql/backuprepo.yaml b/examples/postgresql/backuprepo.yaml
index 890891407..78e96f11b 100644
--- a/examples/postgresql/backuprepo.yaml
+++ b/examples/postgresql/backuprepo.yaml
@@ -1,8 +1,9 @@
 apiVersion: dataprotection.kubeblocks.io/v1alpha1
 kind: BackupRepo
 metadata:
-  name: s3-repo
+  name: <test-backuprepo>
   annotations:
+    # optional, mark this backuprepo as default
     dataprotection.kubeblocks.io/is-default-repo: 'true'
 spec:
   # Specifies the name of the `StorageProvider` used by this backup repository.
@@ -13,24 +14,30 @@ spec:
   # - gcs (Google Cloud Storage)
   # - obs (Huawei Cloud Object Storage)
   # - minio, and other S3-compatible services.
-  storageProviderRef: s3
+  # Note: set the provider name to you own needs
+  storageProviderRef: oss
   # Specifies the access method of the backup repository.
   # - Tool
   # - Mount
+  # If the access mode is Mount, it will mount the PVC through the CSI driver (make sure it is installed and configured properly)
+  # In Tool mode, it will directly stream to the object storage without mounting the PVC.
   accessMethod: Tool
-  # Specifies reclaim policy of the PV created by this backup repository.
-  pvReclaimPolicy: Retain
-  # Specifies the capacity of the PVC created by this backup repository.
-  volumeCapacity: 100Gi
   # Stores the non-secret configuration parameters for the `StorageProvider`.
   config:
-    bucket: <storage-provider-bucket-name>
-    endpoint: ''
-    mountOptions: --memory-limit 1000 --dir-mode 0777 --file-mode 0666
-    region: <storage-provider-region-name>
+    # Note: set the bucket name to you own needs
+    bucket: <kubeblocks-test>
+    # Note: set the region name to you own needs
+    region: <cn-zhangjiakou>
   # References to the secret that holds the credentials for the `StorageProvider`.
+  # kubectl create secret generic demo-credential-for-backuprepo --from-literal=accessKeyId=* --from-literal=secretAccessKey=* --namespace=kb-system
   credential:
     # name is unique within a namespace to reference a secret resource.
-    name: s3-credential-for-backuprepo
+    # Note: set the secret name to you own needs
+    name: <credential-for-backuprepo>
     # namespace defines the space within which the secret name must be unique.
     namespace: kb-system
+  # Specifies reclaim policy of the PV created by this backup repository
+  # Valid Options are [Retain, Delete]
+  # Delete means the volume will be deleted from Kubernetes on release from its claim.
+  # Retain means the volume will be left in its current phase (Released) for manual reclamation by the administrator.
+  pvReclaimPolicy: Retain
diff --git a/examples/postgresql/cluster-cmpd.yaml b/examples/postgresql/cluster-cmpd.yaml
deleted file mode 100644
index c0e791c47..000000000
--- a/examples/postgresql/cluster-cmpd.yaml
+++ /dev/null
@@ -1,41 +0,0 @@
-apiVersion: apps.kubeblocks.io/v1
-kind: Cluster
-metadata:
-  name: pg-cluster
-  namespace: default
-spec:
-  # Specifies the behavior when a Cluster is deleted.
-  # - `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
-  # - `Halt`: Deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations.
-  # - `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
-  # - `WipeOut`: An aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily in non-production environments to avoid irreversible data loss.
-  terminationPolicy: Delete
-  # Specifies a list of ClusterComponentSpec objects used to define the individual components that make up a Cluster. 
-  componentSpecs:
-    # Specifies the name of the Component. This name is also part of the Service DNS name and must comply with the IANA service naming rule. 
-  - name: postgresql
-    # References the name of a ComponentDefinition. The ComponentDefinition specifies the behavior and characteristics of the Component. If both `componentDefRef` and `componentDef` are provided, the `componentDef` will take precedence over `componentDefRef`.
-    componentDef: postgresql-12
-    # Determines whether the metrics exporter needs to be published to the service endpoint.  
-    disableExporter: true
-    # Specifies the name of the ServiceAccount required by the running Component.   
-    serviceAccountName: kb-pg-cluster
-    # Each component supports running multiple replicas to provide high availability and persistence. This field can be used to specify the desired number of replicas.
-    replicas: 2
-    # Specifies the resources required by the Component. It allows defining the CPU, memory requirements and limits for the Component's containers.
-    resources:
-      limits:
-        cpu: '0.5'
-        memory: 0.5Gi
-      requests:
-        cpu: '0.5'
-        memory: 0.5Gi
-    # Specifies a list of PersistentVolumeClaim templates that define the storage requirements for the Component. 
-    volumeClaimTemplates:
-    - name: data
-      spec:
-        accessModes:
-        - ReadWriteOnce
-        resources:
-          requests:
-            storage: 20Gi
diff --git a/examples/postgresql/cluster.yaml b/examples/postgresql/cluster.yaml
index c9ba8fae6..1e69d7459 100644
--- a/examples/postgresql/cluster.yaml
+++ b/examples/postgresql/cluster.yaml
@@ -5,31 +5,71 @@ metadata:
   namespace: default
 spec:
   # Specifies the behavior when a Cluster is deleted.
+  # Valid options are: [DoNotTerminate, Delete, WipeOut] (`Halt` is deprecated since KB 0.9)
   # - `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
-  # - `Halt`: Deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations.
   # - `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
   # - `WipeOut`: An aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily in non-production environments to avoid irreversible data loss.
   terminationPolicy: Delete
-  # Specifies a list of ClusterComponentSpec objects used to define the individual components that make up a Cluster. This field allows for detailed configuration of each component within the Cluster.
-  # Note: `shardingSpecs` and `componentSpecs` cannot both be empty; at least one must be defined to configure a cluster.
-  # ClusterComponentSpec defines the specifications for a Component in a Cluster.
+  # Specifies the name of the ClusterDefinition to use when creating a Cluster.
+  # Note: DO NOT UPDATE THIS FIELD
+  # The value must be `postgresql` to create a PostgreSQL Cluster
+  clusterDef: postgresql
+  # Specifies the name of the ClusterTopology to be used when creating the
+  # Cluster.
+  # Valid options are: [replication]
+  topology: replication
+  # Specifies a list of ClusterComponentSpec objects used to define the
+  # individual Components that make up a Cluster.
+  # This field allows for detailed configuration of each Component within the Cluster
   componentSpecs:
-  - name: postgresql
-    componentDef: postgresql-14
-    disableExporter: true
-    replicas: 2
-    resources:
-      limits:
-        cpu: '0.5'
-        memory: 0.5Gi
-      requests:
-        cpu: '0.5'
-        memory: 0.5Gi
-    volumeClaimTemplates:
-    - name: data
-      spec:
-        accessModes:
-        - ReadWriteOnce
-        resources:
-          requests:
-            storage: 20Gi
+    - name: postgresql
+      # ServiceVersion specifies the version of the Service expected to be
+      # provisioned by this Component.
+      # Valid options are: [12.14.0,12.14.1,12.15.0,14.7.2,14.8.0,15.7.0,16.4.0]
+      serviceVersion: "14.7.2"
+      # Determines whether metrics exporter information is annotated on the
+      # Component's headless Service.
+      # Valid options are [true, false]
+      disableExporter: true
+      # Specifies Labels to override or add for underlying Pods, PVCs, Account & TLS
+      # Secrets, Services Owned by Component.
+      labels:
+        # PostgreSQL's CMPD specifies `KUBERNETES_SCOPE_LABEL=apps.kubeblocks.postgres.patroni/scope` through ENVs
+        # Te KUBERNETES_SCOPE_LABEL is used to define the label key that Patroni will use to tag Kubernetes resources.
+        # This helps Patroni identify which resources belong to the specified scope (or cluster) used to define the label key
+        # that Patroni will use to tag Kubernetes resources.
+        # This helps Patroni identify which resources belong to the specified scope (or cluster).
+        #
+        # Note: DO NOT REMOVE THIS LABEL
+        # update the value w.r.t your cluster name
+        # the value must follow the format <cluster.metadata.name>-postgresql
+        # which is pg-cluster-postgresql in this examples
+        # replace `pg-cluster` with your cluster name
+        apps.kubeblocks.postgres.patroni/scope: pg-cluster-postgresql
+      # Update `replicas` to your need.
+      replicas: 2
+      # Specifies the resources required by the Component.
+      resources:
+        limits:
+          cpu: "0.5"
+          memory: "0.5Gi"
+        requests:
+          cpu: "0.5"
+          memory: "0.5Gi"
+      # Specifies a list of PersistentVolumeClaim templates that define the storage
+      # requirements for the Component.
+      volumeClaimTemplates:
+        # Refers to the name of a volumeMount defined in
+        # `componentDefinition.spec.runtime.containers[*].volumeMounts
+        - name: data
+          spec:
+            # The name of the StorageClass required by the claim.
+            # If not specified, the StorageClass annotated with
+            # `storageclass.kubernetes.io/is-default-class=true` will be used by default
+            storageClassName: ""
+            accessModes:
+              - ReadWriteOnce
+            resources:
+              requests:
+                # Set the storage size as needed
+                storage: 20Gi
\ No newline at end of file
diff --git a/examples/postgresql/config-wal-g.yaml b/examples/postgresql/config-wal-g.yaml
index 49c4d0d74..7467cb7d4 100644
--- a/examples/postgresql/config-wal-g.yaml
+++ b/examples/postgresql/config-wal-g.yaml
@@ -15,4 +15,4 @@ spec:
   # Determines whether the backup contents stored in the backup repository should be deleted when the backup custom resource(CR) is deleted. Supported values are `Retain` and `Delete`. - `Retain` means that the backup content and its physical snapshot on backup repository are kept.
   # - `Retain` means that the backup content and its physical snapshot on backup repository are kept.
   # - `Delete` means that the backup content and its physical snapshot on backup repository are deleted.
-  deletionPolicy: Delete
+  deletionPolicy: Delete
\ No newline at end of file
diff --git a/examples/postgresql/configure.yaml b/examples/postgresql/configure.yaml
index 67bef1514..4f13a64f2 100644
--- a/examples/postgresql/configure.yaml
+++ b/examples/postgresql/configure.yaml
@@ -1,17 +1,19 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-reconfiguring
   namespace: default
 spec:
+  # Specifies the type of this operation.
+  type: Reconfiguring
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   # Instructs the system to bypass pre-checks (including cluster state checks and customized pre-conditions hooks) and immediately execute the opsRequest, except for the opsRequest of 'Start' type, which will still undergo pre-checks even if `force` is true.  Note: Once set, the `force` field is immutable and cannot be updated.
   force: false
   # Specifies a component and its configuration updates. This field is deprecated and replaced by `reconfigures`.
-  reconfigure:
+  reconfigures:
     # Specifies the name of the Component.
-    componentName: postgresql
+  - componentName: postgresql
    # Contains a list of ConfigurationItem objects, specifying the Component's configuration template name, upgrade policy, and parameter key-value pairs to be updated.
     configurations:
       # Sets the parameters to be updated. It should contain at least one item.
@@ -23,14 +25,10 @@ spec:
         # These parameters are used to update the specified configuration settings.
         parameters:
           # Represents the name of the parameter that is to be updated.
-        - key: shared_buffers
+          # `max_connections` is a dyamic parameter in PostgreSQL that can be changed or updated at runtime without requiring a restart of the database
+        - key: max_connections
           # Represents the parameter values that are to be updated.
           # If set to nil, the parameter defined by the Key field will be removed from the configuration file.
-          value: 512MB
-        - key: max_connections
           value: '200'
       # Specifies the name of the configuration template.
-      name: postgresql-configuration
-  # Specifies the maximum number of seconds the OpsRequest will wait for its start conditions to be met before aborting. If set to 0 (default), the start conditions must be met immediately for the OpsRequest to proceed.
-  preConditionDeadlineSeconds: 0
-  type: Reconfiguring
+      name: postgresql-configuration
\ No newline at end of file
diff --git a/examples/postgresql/expose-disable.yaml b/examples/postgresql/expose-disable.yaml
index e04f17261..dc31ab9a3 100644
--- a/examples/postgresql/expose-disable.yaml
+++ b/examples/postgresql/expose-disable.yaml
@@ -1,22 +1,23 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-expose-disable
   namespace: default
 spec:
+  # Specifies the type of this operation.
+  type: Expose
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   # Lists Expose objects, each specifying a Component and its services to be exposed.
   expose:
     # Specifies the name of the Component.
   - componentName: postgresql
-    # Specifies a list of OpsService. When an OpsService is exposed, a corresponding ClusterService will be added to `cluster.spec.services`. 
+    # Specifies a list of OpsService. When an OpsService is exposed, a corresponding ClusterService will be added to `cluster.spec.services`.
     services:
     - name: internet
-      roleSelector: primary
+      # Determines how the Service is exposed. Defaults to 'ClusterIP'.
+      # Valid options are `ClusterIP`, `NodePort`, and `LoadBalancer`.
       serviceType: LoadBalancer
+      roleSelector: primary
     # Indicates whether the services will be exposed. 'Enable' exposes the services. while 'Disable' removes the exposed Service.
     switch: Disable
-  # Specifies the maximum number of seconds the OpsRequest will wait for its start conditions to be met before aborting. If set to 0 (default), the start conditions must be met immediately for the OpsRequest to proceed.
-  preConditionDeadlineSeconds: 0
-  type: Expose
diff --git a/examples/postgresql/expose-enable.yaml b/examples/postgresql/expose-enable.yaml
index bd5be46aa..13d94179b 100644
--- a/examples/postgresql/expose-enable.yaml
+++ b/examples/postgresql/expose-enable.yaml
@@ -1,22 +1,32 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-expose-enable
   namespace: default
 spec:
+  # Specifies the type of this operation.
+  type: Expose
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   # Lists Expose objects, each specifying a Component and its services to be exposed.
   expose:
     # Specifies the name of the Component.
   - componentName: postgresql
-    # Specifies a list of OpsService. When an OpsService is exposed, a corresponding ClusterService will be added to `cluster.spec.services`. 
+    # Specifies a list of OpsService. When an OpsService is exposed, a corresponding ClusterService will be added to `cluster.spec.services`.
     services:
     - name: internet
-      roleSelector: primary
+      # Determines how the Service is exposed. Defaults to 'ClusterIP'.
+      # Valid options are `ClusterIP`, `NodePort`, and `LoadBalancer`.
       serviceType: LoadBalancer
+      # Contains cloud provider related parameters if ServiceType is LoadBalancer.
+      # Following is an example for Aliyun ACK, please adjust the following annotations as needed.
+      annotations:
+        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet
+        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: ""
+        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s1.small
+      # Specifies a role to target with the service.
+      # If specified, the service will only be exposed to pods with the matching
+      # role.
+      roleSelector: primary
     # Indicates whether the services will be exposed. 'Enable' exposes the services. while 'Disable' removes the exposed Service.
-    switch: Enable
-  # Specifies the maximum number of seconds the OpsRequest will wait for its start conditions to be met before aborting. If set to 0 (default), the start conditions must be met immediately for the OpsRequest to proceed.
-  preConditionDeadlineSeconds: 0
-  type: Expose
+    switch: Enable
\ No newline at end of file
diff --git a/examples/postgresql/reconfig-arhive-command.yaml b/examples/postgresql/reconfig-arhive-command.yaml
new file mode 100644
index 000000000..3adc1e0e3
--- /dev/null
+++ b/examples/postgresql/reconfig-arhive-command.yaml
@@ -0,0 +1,21 @@
+apiVersion: operations.kubeblocks.io/v1alpha1
+kind: OpsRequest
+metadata:
+  name: pg-cluster-reconfigure-archive-command
+  namespace: default
+spec:
+  # Specifies the type of this operation.
+  type: Reconfiguring
+  clusterName: pg-cluster
+  reconfigures:
+  - componentName: postgresql
+    configurations:
+    - keys:
+      - key: postgresql.conf
+        parameters:
+          # Represents the name of the parameter that is to be updated.
+          # The archive_command parameter in PostgreSQL is used to specify a shell command that the server runs to archive a completed WAL (Write-Ahead Logging) file.
+          # Here it sets up the necessary environment variables using envdir and then uses wal-g to archive the WAL file
+        - key: archive_command
+          value: "'envdir /home/postgres/pgdata/wal-g/env /home/postgres/pgdata/wal-g/wal-g wal-push %p'"
+      name: postgresql-configuration
\ No newline at end of file
diff --git a/examples/postgresql/restart.yaml b/examples/postgresql/restart.yaml
index e78c1991b..7b8017835 100644
--- a/examples/postgresql/restart.yaml
+++ b/examples/postgresql/restart.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-restart
diff --git a/examples/postgresql/restore-cmpd.yaml b/examples/postgresql/restore-cmpd.yaml
deleted file mode 100644
index 9bd2b0028..000000000
--- a/examples/postgresql/restore-cmpd.yaml
+++ /dev/null
@@ -1,41 +0,0 @@
-apiVersion: apps.kubeblocks.io/v1
-kind: Cluster
-metadata:
-  name: pg-cluster-restore
-  namespace: default
-  annotations:
-    kubeblocks.io/restore-from-backup: '{"postgresql":{"connectionPassword":"<backup-connection-password>","name":"pg-cluster-backup","namespace":"default","volumeRestorePolicy":"Parallel"}}'
-spec:
-  # Specifies the behavior when a Cluster is deleted.
-  # - `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
-  # - `Halt`: Deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations.
-  # - `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
-  # - `WipeOut`: An aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily in non-production environments to avoid irreversible data loss.
-  terminationPolicy: Delete
-  # Specifies a list of ClusterComponentSpec objects used to define the individual components that make up a Cluster. 
-  componentSpecs:
-    # Specifies the name of the Component. This name is also part of the Service DNS name and must comply with the IANA service naming rule. 
-  - name: postgresql
-    # References the name of a ComponentDefinition. The ComponentDefinition specifies the behavior and characteristics of the Component. If both `componentDefRef` and `componentDef` are provided, the `componentDef` will take precedence over `componentDefRef`.
-    componentDef: postgresql-12
-    # Determines whether the metrics exporter needs to be published to the service endpoint.  
-    disableExporter: true
-    # Each component supports running multiple replicas to provide high availability and persistence. This field can be used to specify the desired number of replicas.
-    replicas: 2
-    # Specifies the resources required by the Component. It allows defining the CPU, memory requirements and limits for the Component's containers.
-    resources:
-      limits:
-        cpu: '1'
-        memory: 1Gi
-      requests:
-        cpu: '1'
-        memory: 1Gi
-    # Specifies a list of PersistentVolumeClaim templates that define the storage requirements for the Component. 
-    volumeClaimTemplates:
-    - name: data
-      spec:
-        accessModes:
-        - ReadWriteOnce
-        resources:
-          requests:
-            storage: 30Gi
diff --git a/examples/postgresql/restore.yaml b/examples/postgresql/restore.yaml
index 43a9f9a72..29a93f740 100644
--- a/examples/postgresql/restore.yaml
+++ b/examples/postgresql/restore.yaml
@@ -1,37 +1,36 @@
 apiVersion: apps.kubeblocks.io/v1
 kind: Cluster
 metadata:
-  name: pg-cluster-restore
+  name: pg-restore
   namespace: default
   annotations:
-    kubeblocks.io/restore-from-backup: '{"postgresql":{"connectionPassword":"<backup-connection-password>","name":"pg-cluster-backup","namespace":"default","volumeRestorePolicy":"Parallel"}}'
+    # NOTE: replace <ENCRYPTED-SYSTEM-ACCOUNTS> with the accounts info from you backup
+    kubeblocks.io/restore-from-backup: '{"postgresql":{"encryptedSystemAccounts":"<ENCRYPTED-SYSTEM-ACCOUNTS>","name":"pg-cluster-pg-basebackup","namespace":"default","volumeRestorePolicy":"Parallel"}}'
 spec:
-  # Specifies the behavior when a Cluster is deleted.
-  # - `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
-  # - `Halt`: Deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations.
-  # - `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
-  # - `WipeOut`: An aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily in non-production environments to avoid irreversible data loss.
   terminationPolicy: Delete
-  # Specifies a list of ClusterComponentSpec objects used to define the individual components that make up a Cluster. This field allows for detailed configuration of each component within the Cluster.
-  # Note: `shardingSpecs` and `componentSpecs` cannot both be empty; at least one must be defined to configure a cluster.
-  # ClusterComponentSpec defines the specifications for a Component in a Cluster.
+  clusterDef: postgresql
+  topology: replication
   componentSpecs:
-  - name: postgresql
-    componentDef: postgresql-12
-    disableExporter: true
-    replicas: 2
-    resources:
-      limits:
-        cpu: '1'
-        memory: 1Gi
-      requests:
-        cpu: '1'
-        memory: 1Gi
-    volumeClaimTemplates:
-    - name: data
-      spec:
-        accessModes:
-        - ReadWriteOnce
-        resources:
-          requests:
-            storage: 30Gi
+    - name: postgresql
+      serviceVersion: "14.7.2"
+      disableExporter: true
+      labels:
+        # NOTE: update the label accordingly
+        apps.kubeblocks.postgres.patroni/scope: pg-restore-postgresql
+      replicas: 2
+      resources:
+        limits:
+          cpu: "0.5"
+          memory: "0.5Gi"
+        requests:
+          cpu: "0.5"
+          memory: "0.5Gi"
+      volumeClaimTemplates:
+        - name: data
+          spec:
+            storageClassName: ""
+            accessModes:
+              - ReadWriteOnce
+            resources:
+              requests:
+                storage: 20Gi
\ No newline at end of file
diff --git a/examples/postgresql/horizontalscale.yaml b/examples/postgresql/scale-in.yml
similarity index 65%
rename from examples/postgresql/horizontalscale.yaml
rename to examples/postgresql/scale-in.yml
index f7f177997..95cbe9952 100644
--- a/examples/postgresql/horizontalscale.yaml
+++ b/examples/postgresql/scale-in.yml
@@ -1,7 +1,7 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
-  name: pg-horizontalscaling
+  name: pg-scale-in
   namespace: default
 spec:
   # Specifies the name of the Cluster resource that this operation is targeting.
@@ -11,5 +11,8 @@ spec:
   horizontalScaling:
     # Specifies the name of the Component.
   - componentName: postgresql
-    # Specifies the number of total replicas.
-    replicas: 4
+    # Specifies the replica changes for scaling in components
+    scaleIn:
+      # Specifies the replica changes for the component.
+      # add one more replica to current component
+      replicaChanges: 1
diff --git a/examples/postgresql/scale-out.yaml b/examples/postgresql/scale-out.yaml
new file mode 100644
index 000000000..0a0071dee
--- /dev/null
+++ b/examples/postgresql/scale-out.yaml
@@ -0,0 +1,18 @@
+apiVersion: operations.kubeblocks.io/v1alpha1
+kind: OpsRequest
+metadata:
+  name: pg-scale-out
+  namespace: default
+spec:
+  # Specifies the name of the Cluster resource that this operation is targeting.
+  clusterName: pg-cluster
+  type: HorizontalScaling
+  # Lists HorizontalScaling objects, each specifying scaling requirements for a Component, including desired total replica counts, configurations for new instances, modifications for existing instances, and instance downscaling options
+  horizontalScaling:
+    # Specifies the name of the Component.
+  - componentName: postgresql
+    # Specifies the replica changes for scaling out components
+    scaleOut:
+      # Specifies the replica changes for the component.
+      # add one more replica to current component
+      replicaChanges: 1
diff --git a/examples/postgresql/start.yaml b/examples/postgresql/start.yaml
index ae08b6b84..d2c191358 100644
--- a/examples/postgresql/start.yaml
+++ b/examples/postgresql/start.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-start
diff --git a/examples/postgresql/stop.yaml b/examples/postgresql/stop.yaml
index 2b291fc49..1cc07a968 100644
--- a/examples/postgresql/stop.yaml
+++ b/examples/postgresql/stop.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-stop
diff --git a/examples/postgresql/switchover-specified-instance.yaml b/examples/postgresql/switchover-specified-instance.yaml
index 67b2b4ca1..d3e34005e 100644
--- a/examples/postgresql/switchover-specified-instance.yaml
+++ b/examples/postgresql/switchover-specified-instance.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-switchover-specify
@@ -10,7 +10,7 @@ spec:
   switchover:
     # Specifies the name of the Component.
   - componentName: postgresql
-    # Specifies the instance to become the primary or leader during a switchover operation. The value of `instanceName` can be either: 
+    # Specifies the instance to become the primary or leader during a switchover operation. The value of `instanceName` can be either:
     # - "*" (wildcard value): - Indicates no specific instance is designated as the primary or leader.
     # - A valid instance name (pod name)
-    instanceName: pg-cluster-postgresql-1
+    instanceName: pg-cluster-postgresql-0
diff --git a/examples/postgresql/switchover.yaml b/examples/postgresql/switchover.yaml
index b661f49ff..36e25be9b 100644
--- a/examples/postgresql/switchover.yaml
+++ b/examples/postgresql/switchover.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-switchover
@@ -10,7 +10,7 @@ spec:
   switchover:
     # Specifies the name of the Component.
   - componentName: postgresql
-    # Specifies the instance to become the primary or leader during a switchover operation. The value of `instanceName` can be either: 
+    # Specifies the instance to become the primary or leader during a switchover operation. The value of `instanceName` can be either:
     # - "*" (wildcard value): - Indicates no specific instance is designated as the primary or leader.
     # - A valid instance name (pod name)
     instanceName: '*'
diff --git a/examples/postgresql/upgrade.yaml b/examples/postgresql/upgrade.yaml
index 598e19f0f..d0d83e623 100644
--- a/examples/postgresql/upgrade.yaml
+++ b/examples/postgresql/upgrade.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-upgrade
@@ -7,7 +7,8 @@ spec:
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   type: Upgrade
-  # Specifies the cluster version by specifying clusterVersionRef.
   upgrade:
-    # A reference to the name of the ClusterVersion.
-    clusterVersionRef: postgresql-12.15.0
+    components:
+    - componentName: postgresql
+      # Specifies the desired service version of component
+      serviceVersion: "14.8.0"
\ No newline at end of file
diff --git a/examples/postgresql/verticalscale.yaml b/examples/postgresql/verticalscale.yaml
index 092181cff..297358e9c 100644
--- a/examples/postgresql/verticalscale.yaml
+++ b/examples/postgresql/verticalscale.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-verticalscaling
@@ -7,7 +7,7 @@ spec:
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   type: VerticalScaling
-  # Lists VerticalScaling objects, each specifying a component and its desired compute resources for vertical scaling. 
+  # Lists VerticalScaling objects, each specifying a component and its desired compute resources for vertical scaling.
   verticalScaling:
   - componentName: postgresql
     # VerticalScaling refers to the process of adjusting the compute resources (e.g., CPU, memory) allocated to a Component. It defines the parameters required for the operation.
diff --git a/examples/postgresql/volumeexpand.yaml b/examples/postgresql/volumeexpand.yaml
index 54304da15..ce9bfdfc4 100644
--- a/examples/postgresql/volumeexpand.yaml
+++ b/examples/postgresql/volumeexpand.yaml
@@ -1,4 +1,4 @@
-apiVersion: apps.kubeblocks.io/v1alpha1
+apiVersion: operations.kubeblocks.io/v1alpha1
 kind: OpsRequest
 metadata:
   name: pg-volumeexpansion
@@ -7,7 +7,7 @@ spec:
   # Specifies the name of the Cluster resource that this operation is targeting.
   clusterName: pg-cluster
   type: VolumeExpansion
-  # Lists VolumeExpansion objects, each specifying a component and its corresponding volumeClaimTemplates that requires storage expansion. 
+  # Lists VolumeExpansion objects, each specifying a component and its corresponding volumeClaimTemplates that requires storage expansion.
   volumeExpansion:
     # Specifies the name of the Component.
   - componentName: postgresql