> For the complete documentation index, see [llms.txt](https://docs.tessell.com/tessell/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tessell.com/tessell/database-engines/tessell-for-postgresql/db-services/readme-postgresql/homepage-postgresql/instances-postgresql.md). # Instances The Instances tab displays all configured instances for your PostgreSQL database service in a table, with per-instance details and actions including switchover, DR drills, and replica creation. *** ## What instance topologies does Tessell support for PostgreSQL? | Instance type | Description | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Single instance** | One instance in a given region and availability zone. | | **Multi-AZ (HA)** | Two instances — one primary and one synchronous replica — in the same region (same or different AZ). Both instances are always homogeneous (infrastructure, parameters, storage, IOPS). All planned operations run in rolling mode to minimise downtime. | | **Disaster Recovery (DR)** | One or more async replica instances added in the same or a different region. No automatic failover. Can be added to both single-instance and Multi-AZ services. | | **Read Replica (RR)** | An async replica opened in read-only mode. Use for read-only query offloading. | *** ## How do I add a High Availability (HA) replica? You can convert a single-instance (SI) service to HA, even if it already has DR or Read Replica instances attached — the existing DR/RR instances remain intact and continue replicating from the new HA primary after conversion. **Prerequisites:** Open bi-directional network communication between the primary and HA subnets at the subnet level for the primary database port (e.g., 5432 for PostgreSQL) and port 1599. This must cover the entire CIDR blocks of the subnets. NSG rules must be applied at the subnet level, not the VM level — VM-level NSG is managed by Tessell. ### Steps to add an HA instance 1. Click **Create Replica** (top-right of the Instances tab) → select **High Availability**. 2. In the **Add High Availability Instance** window: * Select an **Availability Zone** from the dropdown. Region and VNet stay the same as the primary and cannot be changed. * Select an available **Private Subnet** from the dropdown. * Review the HA properties inherited from the primary — Compute shape, vCPUs, Storage, Encryption Key, IOPS, Throughput. These cannot be changed for HA. 3. Click **Create**. > **Note:** > > * Brief downtime (typically 30–60 seconds) occurs when the primary PostgreSQL service is stopped and restarted under Patroni management. Tessell automatically: 1. Runs pre-conversion validation on the SI service. 2. Provisions the secondary compute (creates the secondary VM). 3. Installs the required software (PostgreSQL, Patroni, and etcd). 4. Sets up the etcd cluster (forms quorum with the primary, standby, and controller). 5. Configures the primary — converts standalone PostgreSQL into a Patroni-managed cluster. 6. Synchronises the standby — clones data from the primary using `pg_basebackup`. *** ## How do I add a DR or Read Replica instance? You must open bi-directional network communication between the primary and the DR/RR subnets: * **Primary database port** (e.g., 5432 for PostgreSQL, or your specific database port) * **Port 1599** * Applied at the **subnet level** (entire CIDR blocks), not VM level — NSG rules at the VM level are managed by Tessell. ### Steps to add a DR or Read Replica instance 1. Click **Create Replica** (top-right of the Instances tab) → select **Disaster Recovery** or **Read Only Replica**. 2. Provide the following details: * **Instance Name** — alphanumeric characters only. * **Region** — target region. * **Availability Zone** — target AZ. * **VPC** — target VPC. * **Private Subnet** — target private subnet. 3. Click **Add Instance**. Tessell automatically: 1. Submits the request to add the replica. 2. Creates the compute instance(s). 3. Prepares the primary database to accept the new replica. 4. Configures the replica with primary database information. 5. Sets up the Availability Machine for the new instance. As an alternative, use the **Code** button to view, copy, or download the API call for adding an instance in Shell, Python, Go, Java, JavaScript, or PowerShell. *** ## What columns appear in the Instances table? | Column | Description | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Auto-generated name: `default-node-0` (primary), `default-node-1` (typically the HA replica configured for automatic failover), `-node-` (RR/DR, digit incrementing per node added). | | **Status** | Current instance state (see table below). | | **Role** | Primary, HA Replica (Automatic Failover), Read Replica (RR), or Disaster Recovery (DR). Shows the server name below the role. | | **Server** | Server where the instance is deployed. Click the server name to open its home page in the Servers app. | | **Region/Zone** | Cloud provider and region hosting the instance. | | **Parameter Profile** | Parameter profile applied at provisioning. | | **Compute** | Compute shape with vCPU and memory details below. | | **Created** | Date and time the instance was created. | | **Storage** | Storage size; click **See details** for storage provider, throughput, and IOPS. | | **Connection Endpoint** | Hostname; click **See details** for Service URL, Host, Port, and Username. | #### Instance status reference | Status | Description | Actions allowed | | -------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------- | | **UP** | Instance is running and accepting connections. | Resize compute/storage, update parameter profile, delete (RR/DR only) | | **DOWN** | Instance is down. | Raise a Tessell support ticket to have it revived | | **STOPPED** | Instance is completely stopped. | Start the service | | **CREATING** | Provisioning is in progress, or a new instance is being added to the service. | No actions | | **DELETING** | Deletion in progress (RR/DR only). | No actions | | **REBUILDING** | Compute or storage resize in progress. | No actions | | **REBUILD\_FAILED** | Resize was triggered and did not complete. | All actions | | **PATCHING** | A patch is being applied. | No actions | | **PATCH\_FAILED** | Patching failed. | All actions | | **UPDATING\_PARAMETER\_PROFILE** | Parameter profile update in progress. | No actions | | **PARAMETER\_PROFILE\_UPDATE\_FAILED** | Parameter profile update failed. | All actions | > **Note:** Using the ellipsis icon on individual instance rows, you can create, update, or delete private links for DR and RR nodes separately. Creation of private links for DR and RR nodes is currently supported for **AWS cloud only**. *** ## How do I manually trigger a switchover to a replica? Switchover promotes a replica (HA or DR) to become the new primary. > **Note:** Switching over to an instance may cause some downtime for the service. If an HA replica is chosen as the target, the switchover is graceful (planned and synchronised with no data loss) and a switchback is allowed. ### Steps to initiate a switchover 1. Click **Switch over** on the Instances tab. 2. In the **Switch over to an instance** window, select the target replica instance from the list of available replicas (shown with their names and statuses). 3. Optionally add comments. 4. Select the **I understand the consequences** checkbox. 5. Click **Switch**. 6. Monitor progress by clicking **Submitting Request** below the service name. Once the switchover completes, the service returns to **Ready** status and Tessell metadata is updated. *** ## What is the difference between a DR Drill and an actual disaster recovery switchover? When switching over to a DR instance, Tessell offers two paths, controlled by the **DR Drill** flag: | Mode | DR Drill option selected | Behaviour | | -------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **DR Drill (Graceful Switchover)** | Yes | Attempts a graceful switchover: the DR instance is checked for replication sync with the primary, the current primary is demoted in a controlled manner, and the DR instance is promoted with data consistency. If the DR instance is out of sync, the switchover fails to prevent data inconsistency. Used for DR testing and compliance drills — switch back to the original primary is possible after testing. | | **Actual Disaster Recovery (Forceful Switchover)** | No | Treats the scenario as a real disaster. Tessell forcefully promotes the DR instance to primary and brings down the original primary. The DR node requires a manual rebuild to restore replication consistency. Use only for an actual failover. | > **Note:** Ensure you select the **DR Drill** option when performing a planned DR test. Initiating a switchover without the DR Drill option enabled treats the operation as a real disaster recovery and brings down the original primary.

Figure 1 — Instances tab

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.tessell.com/tessell/database-engines/tessell-for-postgresql/db-services/readme-postgresql/homepage-postgresql/instances-postgresql.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.