Debug Postgres from the terminal withneon inspect db

You can now run read-only Postgres diagnostics straight from the Neon CLI with neon inspect db. Each subcommand runs a single, known-good query against Postgres' own statistics and catalog views, then prints a clean table (or JSON/YAML for scripting). There's no connection string to assemble and no catalog view to recall: the CLI resolves the endpoint, role, password, and database through the same Neon API the SDK uses, so you name a diagnostic and go.

New to the Neon CLI?

Install it with npm install -g neon, then authenticate with neon auth. See the install guide and CLI quickstart to get going.

Fourteen subcommands cover the questions you actually ask when something is slow, grouped by what you're chasing:

  • Size and storage: table-sizes, index-sizes, bloat
  • Indexes and scans: unused-indexes, seq-scans
  • Live activity and contention: long-running-queries, locks
  • Query workload: outliers, calls (from pg_stat_statements)
  • Maintenance: vacuum-stats
  • Replication: replication-slots, subscriptions
  • Neon cache debugging: lfc-hit-rate, working-set

Every command is read-only, scoped to the columns that answer the question, and capped where results can get large. That makes it as safe to hand to an agent as it is to run yourself. Point it at a linked project, or at any Postgres database with --db-url:

neon link                 # or: neon set-context --project-id <project-id>
neon inspect db bloat
neon inspect db outliers --db-url postgres://<user>:<password>@<host>:5432/<dbname>

See the neon inspect reference for the full command reference, and read the deep dive on our blog.

Manage snapshots from the Neon CLI

The Neon CLI now has a first-class neon snapshots command group. Snapshots are point-in-time backups of a branch, and they were previously only available in the Console and REST API. You can manage the full lifecycle from your terminal:

  • neon snapshots list and neon snapshots get to see your snapshots.
  • neon snapshots create to snapshot a branch, optionally at a point in time with --timestamp or --lsn.
  • neon snapshots update and neon snapshots delete to rename, re-expire, or remove a snapshot.
  • neon snapshots restore to restore a snapshot into a branch, with a preview step so you can inspect the result before running neon snapshots finalize to commit it.

For example, snapshot a branch before a risky migration, then restore it into a new branch if you need to roll back:

neon snapshots create --branch main --name pre-migration
neon snapshots list
neon snapshots restore pre-migration --name recovered

You can also view and set a branch's automatic backup schedule with neon snapshots schedule get and neon snapshots schedule set. Automated backup schedules are available on paid plans, except for the Agent plan. See the neon snapshots reference for the full list of subcommands.

Create projects with more control from the CLI

neon projects create now accepts flags to configure a project up front: choose the PostgreSQL version, create protected branches, and enable logical replication.

neon projects create --name my-app --pg-version 17
neon branches create --project-id <project-id> --name production --protected
neon projects update <project-id> --enable-logical-replication --yes

See the neon projects reference for the full list of flags.

Query Functions and Storage logs from the Neon MCP server

Functions and Object Storage are core pieces of the Neon backend: serverless compute and S3-compatible storage that branch with your database in the same project. You can now query logs from both services directly through the Neon MCP server, so your AI assistant can investigate a failure without leaving your editor. Three new read-only tools make up the observability category:

  • query_logs: filter logs by source, service, severity, or a text match over a time window (or drop down to raw LogQL for full control).
  • list_log_fields: discover the fields you can filter on.
  • list_log_field_values: list the values a field takes, to ground your filters.

Once the MCP server is connected, ask your assistant in plain language:

Why did my function error in the last hour? Check the logs.

The same logs are documented under Neon Functions logs and object storage logs.

New guides for building on the Neon backend

Two new guides show how to build on the Neon backend, from declaring your services to shipping a real app:

Set up the Neon backend with your AI agent

The backend services (Object Storage, Functions, and AI Gateway) are in beta in AWS us-east-2. To build with them, install the Neon agent skills so your assistant knows how to provision and wire them up:

npx neon@latest init

Then ask your assistant to get started with Neon. See the backend beta guide for access and setup.