# Nistro AI Postgres

Create, connect to and operate managed PostgreSQL deployments.

Nistro AI Postgres runs managed PostgreSQL. You pick the size and placement, and Nistro AI provisions and operates the database.

## Plans

| | On-Demand | Scale |
| --- | --- | --- |
| Compute | 1 to 8 vCPU on shared hosts, with 4 GiB of memory per vCPU | Set by the instance type you choose; each node gets its own machine |
| Storage | 10 GiB to 1 TiB | 10 GiB to 4 TiB |
| PostgreSQL version | 18 | 14 to 18 (default 18) |
| Placement | A location: Any, US, EU or Asia | A location, cloud and region, plus an optional instance type |
| High availability | Single instance | 0 to 8 standby replicas (default 1) |
| Endpoints | Writer | Writer and reader |
| Workload presets | Yes, with locked values | Yes, as a starting point you can override |
| Parameters and extensions | Not available | 50 tunable parameters and 30 extensions |
| Superuser access | Not available | Optional |
| Backups | Not available | Daily, kept for 3 days, plus snapshots you take |
| DBA support add-on | Not available | Optional |

Enterprise deploys Nistro AI Postgres into your own cloud account and is set up with our team. To ask for it, select the **Enterprise** plan in the create flow and then **Contact us**.

## Create a deployment

Open **Postgres Deployments** in the console and select **Create**. Pick a plan, fill in the requirements, select **Load pricing**, review the offer, then select **Deploy**. The deployment's page opens and shows its progress.

### On-Demand

The requirements step has four sections:

- **Capacity**: vCPU (1 to 8), memory (4 GiB per vCPU, set together with vCPU) and storage (10 to 1024 GiB).
- **Workload**: an optional [workload preset](#workload-presets).
- **Database**: the database name, username and password. New databases are created on PostgreSQL 18.
- **Placement**: the location. **Any**, the default, lets Nistro AI pick the lowest-priced location; you can also choose US, EU or Asia. Nistro AI chooses the host, and a deployment created with Any shows its location as **Nistro Managed**.

![The On-Demand requirements step: capacity sliders, workload presets and database settings](https://nistro.ai/images/docs/postgres-create.png)

### Scale

The requirements step has these sections:

- **Placement**: location, then cloud and region, then instance type. Leave the instance type on **Any** to use the cheapest instance available in that region.
- **Storage**: 10 to 4096 GiB per node.
- **High availability**: the number of standby replicas, from 0 to 8. Each standby runs on its own node. With 0 standbys the database has no failover target, and the console warns you.
- **Database**: the PostgreSQL version (14 to 18), database name, username and password. The version can't be changed in the console after the deployment is created.
- **Support**: the optional [DBA support add-on](#dba-support-add-on).
- **Advanced** (optional): [superuser access](#superuser-access), a workload preset, [parameters](#parameters) and [extensions](#extensions).

### Database name, user and password

- The database name and username are required and default to `app`. They can use lowercase letters, numbers and underscores, must start with a letter or underscore, and can be up to 63 characters.
- The password is optional. Leave it blank and a 24-character password is generated for you. If you set one, it must be 12 to 128 characters of letters, numbers and `! @ # $ % ^ & * ( ) _ + = . -`.

## Connect

When the status is **Running**, the deployment's **Overview** shows:

- **Writer endpoint**: the host for reads and writes, as `postgres://<host>:5432`.
- **Reader endpoint** (Scale): a host for read-only queries, spread across the standbys. With 0 standbys it routes to the primary.
- **Database**, **Username** and **Password**. The password is masked; reveal or copy it at any time.

![A running deployment's Overview with its endpoint, database, username and masked password](https://nistro.ai/images/docs/postgres-connect.png)

The **Quick test** card has a `psql` command with every value filled in. Copy it, or build the connection string yourself:

```bash
psql 'postgresql://<username>:<password>@<host>:5432/<database>'
```

Applications take the same connection string, for example as an environment variable:

```bash
export DATABASE_URL='postgresql://<username>:<password>@<host>:5432/<database>'
```

> **Note:** If the password contains characters such as `@`, `#` or `%`, percent-encode them in the connection string. The **Quick test** command does this for you.

## Workload presets

A workload preset tunes PostgreSQL for a kind of workload. Its values are sized to the deployment's vCPU and memory.

| Preset | For |
| --- | --- |
| OLTP | Short transactional queries and many small writes. |
| OLAP | Large scans, sorts and aggregations. |
| Queuing | Job and message queues with constant inserts and deletes. |
| Full text search | Text search over GIN indexes. |

Every preset sets `shared_buffers` to 25% of memory and `effective_cache_size` to 75%, sizes `work_mem` and `maintenance_work_mem` to memory, and sets `max_connections`, `checkpoint_completion_target` and `random_page_cost`. Each preset then adjusts the settings that matter for its workload:

- **OLTP** turns off JIT compilation and makes autovacuum run more often.
- **OLAP** allows fewer connections, more `work_mem` per query, larger planner statistics and parallel workers.
- **Queuing** turns off JIT compilation, makes autovacuum run much more often, and closes sessions left idle in a transaction for 60 seconds.
- **Full text search** raises `work_mem`, `maintenance_work_mem` and planner statistics, and sets `gin_pending_list_limit`.

On **On-Demand**, the preset's values are locked. You can switch to another preset after creating the deployment, but you can't go back to no preset. Resizing recalculates the preset's values.

On **Scale**, the preset is a starting point: its values are sized to the instance when the deployment is created, and any parameter you add overrides the preset's value.

## Parameters

Scale deployments can set these `postgresql.conf` parameters, at create time under **Advanced** or later under **Config > Advanced configuration**:

`work_mem`, `maintenance_work_mem`, `gin_pending_list_limit`, `shared_buffers`, `effective_cache_size`, `hash_mem_multiplier`, `effective_io_concurrency`, `random_page_cost`, `default_statistics_target`, `jit`, `join_collapse_limit`, `max_parallel_workers`, `max_parallel_workers_per_gather`, `max_parallel_maintenance_workers`, `max_connections`, `statement_timeout`, `lock_timeout`, `idle_in_transaction_session_timeout`, `idle_session_timeout`, `deadlock_timeout`, `autovacuum_vacuum_scale_factor`, `autovacuum_analyze_scale_factor`, `autovacuum_vacuum_cost_limit`, `autovacuum_vacuum_cost_delay`, `autovacuum_naptime`, `autovacuum_max_workers`, `autovacuum_work_mem`, `vacuum_cost_limit`, `vacuum_cost_delay`, `max_wal_size`, `min_wal_size`, `checkpoint_completion_target`, `checkpoint_timeout`, `wal_compression`, `synchronous_commit`, `log_min_duration_statement`, `log_statement`, `log_min_messages`, `log_lock_waits`, `log_temp_files`, `log_autovacuum_min_duration`, `log_connections`, `log_disconnections`, `track_io_timing`, `track_activity_query_size`, `pg_stat_statements.max`, `pg_stat_statements.track`, `timezone`, `default_transaction_isolation`, `temp_file_limit`.

Other parameters are rejected. Changing `shared_buffers`, `max_connections`, `autovacuum_max_workers`, `track_activity_query_size` or `pg_stat_statements.max` triggers a rolling restart; the console marks these with **restart**.

## Superuser access

Scale and Enterprise deployments can turn on the PostgreSQL superuser (`postgres`): select **Enable superuser** under **Advanced** when you create the deployment, or turn it on or off later from **Config > Advanced configuration**. On-Demand deployments don't offer superuser access.

## Extensions

Scale deployments can enable these extensions when they are created:

`vector`, `pgcrypto`, `hstore`, `citext`, `uuid-ossp`, `pg_trgm`, `ltree`, `tablefunc`, `unaccent`, `btree_gin`, `btree_gist`, `fuzzystrmatch`, `intarray`, `earthdistance`, `cube`, `pg_stat_statements`, `isn`, `seg`, `tcn`, `moddatetime`, `pgrowlocks`, `bloom`, `tsm_system_rows`, `tsm_system_time`, `dict_int`, `dict_xsyn`, `autoinc`, `insert_username`, `intagg`, `refint`.

Pick them under **Advanced** in the create flow. You can't change the selection after the deployment is created. In `psql`, `\dx` lists the extensions installed in your database.

## High availability

Scale deployments run a primary and 0 to 8 standby replicas, each on its own node. The reader endpoint spreads read-only queries across the standbys (or uses the primary when there are none), and if the primary fails, a standby is promoted automatically.

- **Change the number of standbys** from **Config > High availability**.
- **Switch over manually** from **Health > Nodes**: select **Switch over** on a standby and type `switch` to confirm. Writes pause briefly and connections may need to reconnect.

## Backups and snapshots

Scale deployments are backed up daily, and each backup is kept for 3 days. Automated backups can't be deleted.

- **Take a snapshot** from the deployment's **Backups** tab while it's running.
- **Restore** a completed backup or snapshot from the same tab. Restoring creates a new deployment with the source's configuration and leaves the source unchanged. Type `restore` to confirm.

**Snapshots & Backups** in the console lists the backups and snapshots of every deployment in the team. They stay listed after their source deployment is deleted.

## Resize

- **On-Demand**: from **Config > Compute and storage**, change vCPU between 1 and 8 (memory follows) or increase storage, up to 1 TiB.
- **Scale**: increase storage from **Config > Storage** while the deployment is running. Compute is set by the instance type and can't be changed.

Storage can grow but never shrink.

## Stop, start and delete

- **Stop** and **Start** are in the deployment's header.
- **Delete** is in the header and on the **Danger** tab. Type `delete` to confirm. Deleting can't be undone.

## DBA support add-on

Scale deployments can add Standard PostgreSQL DBA support from Command Prompt, a Nistro AI partner. Select it in the **Support** section when you create the deployment.

- It covers help with tuning, schema design, migrations and query troubleshooting during business hours.
- It's billed separately at hourly rates under section 14 of the [Terms of Use](https://nistro.ai/terms).
- After the deployment is created, the console sends the request to our team. If sending fails, the console tells you; email [support@nistro.ai](mailto:support@nistro.ai) to set it up.