Skip to content
Merged
93 changes: 93 additions & 0 deletions docs/using/database-instances.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
# Database Instances
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest renaming this to "Managing Database Instances". You will also need to place it in the mkdocs.yml file so that it's rendered in the menu under "Using Control Plane". I suggest placing it below Read Replicas.


A database instance is:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would revise this top section to keep it short - its likely we need additional articles on managing users and port selection. I would write a few paragraphs that re-iterate what Instances are, and why you might need to manage them. You can pull from the Concepts page for some wording.

* A running Postgres server
* Bound to a specific host
* Identified by a node name (e.g. n1)
* Identified globally by an instance ID
(eg 68f50878-44d2-4524-a823-e31bd478706d-n1-689qacsi)
<br>

Each instance maps to exactly one physical host, but a host can run multiple database instances as long as ports do not clash.
<br>

While a database is stable and persistent, database instances are runtime components with states that are not “identity-critical”. This allows rolling updates, automatic failovers, and safe restarts.

Instances and port ownership
* Ports are unique per host
* Stopping an instance does not “free” the port
* Restarting preserves the same port
* Changing ports requires a plan update and a restart
* Port conflicts cause update failure


Users in the database spec:
* Are reconciled onto each instance
* Get created / updated / dropped during instance configuration
* Must remain consistent across all instances
* Cannot conflict with system users

States
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would pull this information into a subheading "Monitoring Instances" and show the user how you can fetch this information using the GetDatabase endpoint. The user will need to find the instance IDs to use the rest of the operations below.

You can also speak to the postgres status information under each instance, notably the pending_restart field which highlights if a configuration change is pending that requires a restart.

Instances can be in different states as a result of database operations (start/stop/restart/etc):

* `available`
* `starting`
* `stopping`
* `restarting`
* `failed`
* `error`
* `unknown`
<br><br>



# Database Instance Operations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be only 1 top level header per page, so I would remove this and just have:

  • Monitoring Instances
  • Stopping Instances
  • Starting Instances
  • Restarting Instances

## Stop Instance
Stopping an instance shuts down the Postgres process for that specific instance by scaling it to zero. The instance no longer accepts connections and is taken out of service, but its data and configuration are preserved. Other instances in the same database can continue running.
As Stop Instance removes a database instance from service without deleting it, it can be used to isolate an instance not currently in use but that is expected to be restarted later.

* Transition: available → stopping → stopped
* Port remains reserved for this instance
* Other instances remain unaffected
* A stopped instance continues to appear under list-databases with state: "stopped"

Example: Stop a database “example” whose instance ID is “n1”
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Instance IDs are always generated - they look something like this: example-n1-689qacsi, which is <database-id>-<node-name>-<host-id-hash> - let's follow this here and have carry through from our other docs pages that use example.


=== "curl"


```sh
curl http://host-3:3000/v1/databases/example/instances/n1/stop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each of these sample requests is a POST. This might work with a GET, but we should follow the spec accordingly.

```


## Start Instance
Starts a specific instance within a database by scaling it back up. This operation is only valid when the instance is in a stopped state. A successful start instance operation will transition an instance state from stopped to starting to available, allowing normal access and use to continue and restarting any activities
* Transition: stopped → starting → available
* Retains same port as before stop
* Fails if port is already taken (a safety check)

Example: Start a database “example” whose instance ID is “n1”

=== "curl"

```sh
curl http://host-3:3000/v1/databases/example/instances/n1/start
```
## Restart Instance
Restarting an instance stops and then starts the same Postgres instance, either immediately or at a scheduled time. This is typically used to recover from errors or apply changes that require a restart. The instance keeps its identity and data, but experiences a brief downtime during the restart.
* If no scheduled_at is provided → restart immediately.
* Transition: available → restarting → available
* Restart is blocked if:
No configuration changes require a restart
Another update is in progress
Instance is not stable

Example: Start a database “example” whose instance ID is “n1”
=== "curl"


```sh
curl http://host-3:3000/v1/databases/example/instances/n1/restart
```