Skip to main content

Neon

Neon works with pocketPG as a managed PostgreSQL provider. Like Supabase, the important point is that pocketPG monitors Neon through the PostgreSQL connection itself, not through a Neon-specific infrastructure API integration.

What to use when connecting​

Use the direct PostgreSQL connection string from the Neon console.

Avoid pooled endpoints for pocketPG monitoring. Direct connections give pocketPG the most predictable access to workload and backend statistics.

What pocketPG reads normally​

With a direct connection and pg_monitor, pocketPG can still use its normal PostgreSQL-side monitoring path:

  • health and checkpoint diagnostics
  • query analysis from pg_stat_statements
  • WAL and replication-pressure views
  • table and index statistics
  • tuning recommendations based on pg_settings and activity data

Provider-aware behavior​

When an instance is marked as Neon, pocketPG keeps the provider identity so it can:

  • show Neon-specific setup guidance
  • keep managed-provider checkpoint caveats attached
  • distinguish direct PostgreSQL monitoring from provider API monitoring

What is not integrated yet​

Neon does not currently have a separate Infrastructure card in pocketPG for provider API CPU, memory, or disk charts.

That means Neon does not need a dedicated monitoring model like Aiven to be useful in pocketPG today. The correct product shape is provider-specific onboarding and caveats first, then deeper provider integration later if it becomes worth building.