Labsco
openai logo

render-postgres

✓ Official★ 4,081

by openai · part of openai/plugins

Sets up and optimizes Managed PostgreSQL on Render—connection strings (internal vs external), creation constraints, storage autoscaling, connection limits, high availability, read replicas, backups, and MCP inspection. Use when the user mentions Postgres, PostgreSQL, Render database, connection string, DATABASE_URL, backups, snapshots, replicas, HA, disk storage, connection pooling, or troubleshooting DB connectivity.

🧩 One of 7 skills in the openai/plugins package — works on its own, and pairs well with its siblings.

This is the playbook your agent receives when the skill activates — you don't need to read it to use the skill, but it's here to audit before installing.

Render Managed PostgreSQL

This skill covers Managed Postgres on Render: how to connect, what cannot change after creation, storage behavior, limits, HA, replicas, and safe deletion. Deep dives live under references/.

When to Use

Apply this skill when the user:

  • Configures Postgres for an app on Render (URLs, TLS, pooling)
  • Creates or changes a database, plan, disk, or replicas
  • Asks about backups, PITR, exports, or deleting a database
  • Hits connection limits, SSL errors, or latency between services and DB
  • Authors Blueprint databases / readReplicas or wires fromDatabase

For deploy flows and Blueprint basics, see render-deploy and render-blueprints. For private networking between services, see render-networking. For env var patterns, see render-env-vars.

Connection Patterns

Render exposes two connection URLs for the same logical database:

URLUse whenTLS
InternalApp or service on Render in the same region and workspaceNot required (private network)
ExternalLocal development, CI, or tools outside RenderRequired (TLS 1.2+)

Always prefer the internal URL for Render-hosted apps so traffic stays on Render’s network and avoids extra latency and public egress patterns.

  • IP allow list applies to external access only. Same-region Render services use the internal URL regardless of the allow list.
  • External clients must use TLS; misconfigured clients often show SSL handshake or sslmode errors.

URL formats, Dashboard locations, Blueprint fromDatabase, pooling, and common mistakes: references/connection-guide.md.

Storage Management

  • Autoscaling: When disk use reaches roughly ~90%, Render can grow storage by about ~50%, rounded up to the next 5 GB multiple, up to 16 TB max.
  • Cannot shrink disk after an increase.
  • Cooldown: After a storage increase, you cannot increase again for 12 hours.
  • Over limit / unhealthy: If disk is over the configured limit, the database can become unhealthy; Render may suspend it until resolved.

Monitor disk and plan exports or cleanup before you hit hard limits. Backup and restore options: references/backup-and-recovery.md.

Connection Limits

Maximum connections depend on instance RAM (current-generation plans):

RAMMax connections (typical)
Under 8 GB100
8 GB200
16 GB300
32 GB and above500

Legacy database plans may have lower limits; confirm in the Dashboard or API for the specific plan.

Render does not provide a built-in pooler; use application-side pooling (framework pools, PgBouncer, pgpool, etc.). Limits are hard—exhausting them causes connection errors. More detail: references/connection-guide.md and references/performance-tuning.md.

High Availability

High availability (HA) is available when:

  • Workspace is Professional or higher, and
  • Database plan is Pro or higher, and
  • PostgreSQL 13+

Instance type changes cause brief downtime. With HA, downtime is typically less than without HA (often on the order of minutes without HA—exact duration depends on plan and operation).

One-way migration off legacy types: After moving to current-generation instance types, you cannot move back to legacy instance types.

Read Replicas

  • Up to 5 read replicas per database.
  • In Blueprints, declare replicas under readReplicas as a list of names.
  • CAUTION — declarative sync:
    • An empty readReplicas list can destroy all existing replicas.
    • Name mismatches between the Blueprint and live replicas can create new replicas and remove replicas whose names are no longer listed.

Always treat readReplicas as authoritative desired state, not additive-only.

Useful MCP Commands

Use the Render MCP tools (names may vary slightly by integration; align with your server’s tool list):

GoalTool / pattern
List databaseslist_postgres_instances
Instance detailsget_postgres with postgresId
Read-only SQLquery_render_postgres with postgresId and sql
Connection loadget_metrics with resourceId (Postgres ID) and metricTypes: ["active_connections"]

query_render_postgres runs in a read-only transaction and opens a new connection per query—do not use it as a substitute for app pooling.

Shorthand (same tools): list_postgres_instances(), get_postgres(postgresId), query_render_postgres(postgresId, sql), get_metrics(resourceId, metricTypes: ["active_connections"]).

Deleting and Data Safety

  • Backups and snapshots are not retained after you delete the database. Export first (pg_dump, Dashboard restore workflow from existing backups, etc.).
  • Before destructive actions, confirm retention and recovery paths in references/backup-and-recovery.md.

References

DocumentContents
references/connection-guide.mdInternal vs external URLs, SSL, allow list, Blueprint wiring, pooling, multi-database URLs, troubleshooting
references/backup-and-recovery.mdSnapshots, PITR, pg_dump / pg_restore, restore flows, deletion, cross-region
references/performance-tuning.mdpg_stat_statements, indexes, bloat, EXPLAIN ANALYZE, metrics, scaling
  • render-deploy — End-to-end deploy, services, and MCP/Dashboard flows
  • render-blueprints — databases, fromDatabase, readReplicas, immutable fields
  • render-networking — Private services, regions, and how traffic routes between resources
  • render-env-vars — Storing DATABASE_URL and secret wiring patterns