How to resize a customer's Postgres quota

A customer asks for more storage or a larger instance. Where to change quota and instance size, what's immediate, and what triggers a restart.

Last updated 20 days ago

How to resize a customer's Postgres quota

When you'd do this

A customer asks for more storage, more connections, or a larger instance (more CPU / RAM). Or you're downsizing a quiet instance to recoup margin. The how depends on whether the plan is shared or dedicated.

Shared plans: storage and connection quota

Shared tenants run pooled on a PgBouncer host. Quota changes are soft enforcement — no VPS resize, no restart.

  1. Open the ImpulseDB Postgres admin tab > Customers, find the service, click through to the detail page.

  2. Edit the per-tenant quota. The detail page exposes the per-DB storage cap and the PgBouncer connection allocation. Change either field and save.

  3. What happens on save. The addon updates mod_impulsepostgres_instances, applies the storage cap at the database level, and adjusts the PgBouncer pool. The audit log records a quota.updated event with the before/after values. The customer's client-area usage card reflects the new quota on next page load.

Changes apply immediately. The customer's existing connections stay open; the new pool size affects new connections.

Dedicated plans: storage and connection quota

For dedicated tenants, soft quota changes (storage cap and connection pool) work the same as shared — edit on the detail page, save, applied immediately, audit-logged.

What's different is when the customer wants a larger instance (more CPU / RAM, or a bigger disk than the VPS plan provides).

Dedicated plans: instance-size changes (VPS resize)

Moving a customer from, say, Vultr vc2-2c-4gb to vc2-4c-8gb, or DigitalOcean s-2vcpu-4gb to s-4vcpu-8gb, requires resizing the VPS at the provider. The four supported providers (Vultr, Hetzner, DigitalOcean, Linode) each handle resize differently, and in most installs this requires a brief Postgres restart while the VPS reboots into the new size.

The exact UI flow depends on the module version — some installs expose a Resize Instance action on the dedicated server detail page that drives the provider API directly; others document the resize as a console operation against the provider's CLI. Check the Dedicated Servers detail page for a resize action first; if it's not there, the operation is currently provider-side.

What you can rely on:

  • The audit log records the resize event with the before/after VPS plan slug.

  • The customer notification (if configured under Settings > Customer Notifications) sends a maintenance email if you flag the resize as scheduled.

  • Snapshot+restore is wired across all four providers — if the resize fails, the pre-resize snapshot is the rollback path.

If you're not sure whether the resize is automated for your provider, run a Test on the relevant server detail page first, or open a support thread before triggering it on a production instance.

What the audit log shows

Filter Tools > Audit Log to the affected service. You'll see, in order:

  • quota.update_started — the operator action.

  • For VPS resizes: snapshot.created (pre-resize), provider.resize_started, provider.resize_completed, service.restarted.

  • quota.update_completed — final state with the new values.

If anything errored, the failing step will be marked severity=error with the verbatim provider response.

What customers see

The client-area service page Usage card and Plan details reflect the new quota on next reload. For VPS resizes that include a brief restart, the customer sees the connection card show a transient "applying maintenance" state until Postgres comes back up.

Related