Dedicated & shared tier setup

Two ways to sell Postgres: dedicated (one VPS per customer) and shared (multi-tenant on a PgBouncer host). Mix and match per plan.

1. Dedicated vs shared, at a glance

Compared	Dedicated	Shared
Customers per server	1	N (PgBouncer-pooled)
Resource isolation	Full — CPU/RAM/disk are the customer’s alone	Soft — per-database connection limit + storage quota
Provider plan	You pick a VPS size per provider for each plan	Customers route to a pre-existing shared server
Setup time per order	A few minutes (full VPS setup)	Seconds (the role and database are created at order time)
Best for	Apps with predictable load, compliance, larger DBs	Hobby / small projects / staging databases

2. Edit a plan

Open the Plans & Products tab. Click Edit on an example, or add a new plan.

Field	What it does
Display Name & Slug	Customer-visible name and stable internal identifier.
Server Type	Shared or Dedicated.
PostgreSQL Version	The PostgreSQL major the plan runs (16, 17 or 18 — whichever you’ve enabled).
Shared Server	(Shared plans only) Pin to a specific server, or leave as Auto — any server with capacity.
Server Size	(Dedicated only) Click Find Best Server Size to query the active provider, or enter a plan slug directly (Vultr vc2-2c-4gb, Hetzner cx22, DO s-2vcpu-4gb, Linode g6-standard-2). Storage Type can limit it to SSD or NVMe.
Storage / Max Connections / Backup Retention	The quotas you’re selling. Connections are capped per database role. Storage is checked hourly: a database that has grown past its quota is switched to read-only (and you’re notified), then switched back once it’s under again. Backup retention is in days.
Max IP Allowlist / Max PgBouncer Pool Users	How many allowlist entries and pool users a customer can add.
Extensions Tier	Which Postgres extensions the customer can CREATE EXTENSION: Core, Full (adds pgvector and PostGIS) or Full+ (adds pg_cron and TimescaleDB).
Replica Size & Customer Price	(Dedicated only) Optional read-replica VPS size (Find Best Replica Size) and the monthly price the customer pays for the replica add-on.
Monthly / Annual Price	Customer-facing price.

3. Shared server routing

Shared plans get their server from one of two strategies. Either way, only servers running the plan’s PostgreSQL major are considered:

• Pinned — set Shared Server to a specific server. Every customer on this plan goes there — unless the order names a different region, in which case it routes automatically within that region. If the pinned server is full, the order fails rather than landing elsewhere. Use this to separate tiers onto different hardware.
• Auto (default) — the region’s default server first, then the server in the region with the fewest tenants. A server in another region is used only when the order didn’t ask for a specific region.

Each plan card shows a PINNED or AUTO badge in its Infrastructure section.

4. The infrastructure cost & margin column

Each plan card’s Pricing section shows the customer price, the VPS infrastructure cost, and the resulting margin (with markup percentage). Costs are pulled from the active provider’s API and cached for a few hours — Refresh Pricing fetches them again. Replicas, when configured, show as a separate sub-block so you can see total infrastructure exposure at a glance. Shared plans show the shared pool instead of a per-plan VPS cost.

Set prices for actual margin, not a vague markup

The margin is computed from live provider prices, so you can pick a price that gives you the gross margin you want rather than guessing at a markup.

5. Sync to WHMCS

Click Sync All. The addon creates one WHMCS product per plan (named PostgreSQL - <plan>) in a Managed PostgreSQL product group, wires it to the ImpulseDB Postgres server module, sets monthly and annual pricing in every WHMCS currency, assigns a server group whose name contains “Impulse” and “Postgres” if one exists, and adds upgrade paths to larger plans of the same type. A plan with a replica price can also be synced as a WHMCS add-on named Read Replica — <plan>.

Sync doesn’t create configurable options or custom fields. After a sync, the addon shows a checklist of what to finish in WHMCS — for example a “PostgreSQL Version” configurable option if customers should choose the version at order time, a “Database Name” custom field, extra billing cycles, and adding the product to an order form.

Re-running sync is idempotent — existing products are updated in place rather than duplicated, and a product name or description you edited in WHMCS is left alone.

Delete or edit every example plan before going live

A yellow banner appears on the Plans & Products tab whenever any example plan still exists. Example plans are skipped by the sync until you rename them.