Automation · Operations and reporting

Test a change to your Neon database before applying it

An AI agent tests your Neon database schema change on a temporary branch, shows you the differences and applies it only if you approve.

Show me this with my own operation See every automation

How do I test a change to my app's database on Neon without putting the data at risk?

You text your Met on WhatsApp "add a delivery city column to the orders table". The Met finds the Neon project, reviews the tables and the columns of the table you are changing, and prepares the migration on a temporary branch, a copy of the database in its current state. It compares that branch's schema with the parent branch's and shows you the difference before touching anything. If you approve and the admin left the complete migration action on, which starts off, the Met applies it and deletes the temporary branch; otherwise it discards it. Neon recommends this server for development and testing databases, not production.

What starts it

When someone asks for it

It starts when someone on the team or at the agency asks the Met on WhatsApp for a change to the database structure, such as a new column or table. Each change is on request.

A manual task: someone on the team runs it with a button, or asks the Met for it in chat.

Who runs it

Internal Met that handles your Neon database changes

This is not a named, seeded Met. It is an internal Met with Neon connected, for the tech team or the agency that maintains the business's app: it is done when the change is applied or discarded and the temporary branch no longer exists.

Run by the data analyst Met

Channels: WhatsApp

What you need connected

Neon Automate and collaborate

5 steps · 7 tools

The procedure, step by step

Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.

1
Find the Neon project

The Met lists the connected account's projects and opens the one you named, with its configuration and compute, so it does not work on the wrong database.
- list_projects Neon
- describe_project Neon
2
Review the table that changes

The Met lists the database tables and pulls the columns, data types and constraints of the table you are changing. The change starts from what exists, not from what someone recalls.
- get_database_tables Neon
- describe_table_schema Neon
3
Prepare the change on a temporary branch

The Met applies the schema change on a temporary branch to test it before completing it. The parent branch stays the same meanwhile; the temporary branch stays in your Neon account until the change is applied or discarded.
- prepare_database_migration Neon
4
Show you the difference

The Met compares the temporary branch's schema with the parent branch's and sums up on WhatsApp what changes: the new column, its type and its constraints. With that you decide whether it gets applied.
- compare_database_schema Neon
5
Apply or discard

With your answer, the Met completes the migration: it applies or discards it, and deletes the temporary branch. This action starts off and, unless told otherwise, it applies: the Met only uses it if the admin switched it on in Connections.
- complete_database_migration Neon

Before you start

What you need ready

The Met solves none of these for you. If one is missing, the automation stops there.

A Neon account with the app's project

The account your team or agency uses to manage the database on Neon. Neon recommends using this server with development and testing databases, not the production one.
Neon connected with full access

In Met, open Connections → Neon → Connect and authorize with full access, because read-only mode does not create branches or run migrations. To apply, the admin switches on the complete migration action, which starts off.
An internal Met on WhatsApp

A team Met with Neon connected that you text on WhatsApp. It is not the Met that serves your customers: it is for whoever maintains the app.

The limits

What this automation does NOT solve

Better said here than discovered halfway through the rollout.

It is not meant for the production database: Neon recommends its MCP server for development and testing, and not exposing personal data.
It does not ask for confirmation in the chat before applying if the admin switched on the complete migration action: it applies it when you ask. That is why it starts off.
It does not change your code. If the app has to read or write the new column, your team or your agency makes that change.
It does not pay for your Neon plan: the temporary branch and its compute run on your account while they exist.
It does not work in read-only mode: in that mode Neon switches off creating branches and running migrations.

FAQ

Questions about this automation

A copy of the database in its current state where Neon tests the change. The parent branch is not touched until the migration is completed, and completing it deletes the temporary branch.

You tell the Met to discard it: it completes the migration by discarding it and deletes the temporary branch, with the parent branch unchanged.

Neon recommends against it: its MCP server is for development and testing. This procedure is meant for the project where your team tests changes before taking them to production.

You do, with your Neon account and plan. Meteor does not resell Neon: the temporary branch and its compute stay in your company's or your agency's account.

Keep going