Provision Neon Postgres Without Signup

Provision a temporary Neon Postgres database, add data, and claim it.

Introduction

30 Second Summary

Trying a database often begins with registration forms or payment details. That friction can stop a quick experiment before it starts.

In this project, you will provision a temporary Postgres database from your terminal before signing up for Neon. After proving the database works, you will claim the project through a sign-in link.

What You'll Build

You will select rows from a live Postgres database that existed before you created an account.

By the end of this project, you'll have:

Provision without signup: Create a live database from your terminal without an account or card.
Query real data: Add a table with sample rows. Retrieve those rows through a Postgres client and over HTTP.
Claim your project: Accept the transfer through a sign-in link. See the database inside your Neon dashboard.
Secret Mission: Take on an optional challenge to push your skills further.

Are there any prerequisites?

Node must already be available on your laptop. You will also need npm plus psql or another Postgres client.

Before We Start

The anonymous Neon flow starts from your terminal. Your browser takes over only when you are ready to claim the database.

Node.js runs the short database scripts used later. npm provides the command-line packages this project needs.

In this step, get ready to:

Make a terminal available for project commands.
Confirm your browser can open external links.
Confirm the Node.js toolchain can run later database queries.

Open the tools you will use

Your terminal runs every provisioning command in this project. Use the instructions for your operating system to reach a command prompt.

macOS

Press Cmd+Space to open system search.
Type Terminal.
Press Enter to open Terminal.

You should see a terminal window with a command prompt ready for input.

Windows

Press the Windows key to open system search.
Type Windows Terminal.
Select Windows Terminal from the search results.

You should see a terminal window with a command prompt ready for input.

Open the official Node.js website to confirm your browser can load the external claim link later.

You should see the Node.js website with its download options. Your browser is ready for the claim stage.

Which Postgres Client Will You Use?

A Postgres client sends SQL to a database. This project uses a short Node.js script as its client path.

The runtime you verify next supports the later query step. A Neon account is unnecessary at this stage.

Verify Node.js and npm

The anonymous provisioning flow depends on npm for the Neon CLI. A working Node.js runtime also gives you a way to query the database without a separate desktop client.

Before you run the checks, do you expect both commands to return version numbers?

Check the Node.js toolchain by running these commands:

node -v
npm -v

What Do These Checks Show?

The node -v command checks that the Node.js runtime is available through your terminal.
The npm -v command checks that npm is available for installing the Neon CLI.

✔️ Both commands show versions

Good work. Your terminal can run Node.js scripts and install command-line packages.

You should see one version number from each command. The Node.js runtime gives you the short-script route for later Postgres queries.

ⓧ node is not found

The Node.js runtime is missing from your command path. The official installer adds Node.js plus npm.

Visit the official Node.js website.
Choose the release labelled LTS.
Download the installer for your operating system.
Run the downloaded installer.
Keep the default components selected.
Close your current terminal window.
Open a fresh terminal using the earlier instructions.
Rerun the two version checks shown above.

You should now see one Node.js version number plus one npm version number.

ⓧ npm is not found

The Node.js runtime is available without a working npm command. Reinstalling the supported Node.js package restores the complete toolchain.

Visit the official Node.js website.
Choose the release labelled LTS.
Download the installer for your operating system.
Run the downloaded installer.
Keep the default components selected.
Close your current terminal window.
Open a fresh terminal using the earlier instructions.
Rerun the two version checks shown above.

You should now see one Node.js version number plus one npm version number.

Still Missing a Version Number?

A terminal opened before the installation may still use the old command path. Close every terminal window before opening a fresh one.

Ask for targeted help with diagnosing your Node.js installation.

Your local toolchain is ready. Next, you will install the Neon CLI and confirm your terminal can find it.

Install the Neon CLI

Provisioning a database without an account depends on one tool your terminal can call. This installation step puts that tool on your system.

The Neon CLI turns the anonymous claim flow into terminal commands. Installing it globally with npm makes neon available across terminal sessions.

In this step, get ready to:

Install the Neon CLI globally with npm.
Confirm that neon is available on the terminal PATH.

Prepare your terminal

A global installation places the command in the shared executable location managed by npm. Later claim commands can then run from any folder.

Install the latest Neon CLI package globally by running this command:

npm i -g neon@latest

What Does This Command Do?

The npm command downloads the Neon CLI package.
The -g flag installs the package in the global npm location.
The @latest tag selects the current release.

Good progress. The Neon CLI package is now installed globally.

Installation Failed in npm?

A failed global installation usually points to network access, npm permissions, or an older Node.js release.

Check your internet connection before retrying the installation.
Confirm that your current user can install global npm packages.
Check that Node.js is version 20.19.0 or higher.
Ask for targeted help with fixing the Neon CLI installation.

Test terminal access

Your shell uses PATH to find executable commands. A version check proves that the Neon CLI is reachable from this terminal session.

Before you run the check, do you expect your shell to return a version number?

Verify the installed CLI by running this command:

neon --version

What Does This Command Do?

The command asks the neon executable to report its installed version. A version number proves the package is callable from this terminal session.

✔️ I see a version number

That setup is locked in. The version number confirms that neon is available on your terminal PATH.

ⓧ Command not found

The package may be installed while this terminal session still has an older PATH value.

Restart the terminal session from earlier.
Check the CLI again by running this command:

neon --version

What Does This Command Do?

The fresh terminal session reloads your executable search path. The version command checks whether it can now find neon.

You should now see the installed Neon CLI version number.

Still Cannot Find the CLI?

Confirm that the npm installation completed without reporting a failure.
Confirm that the global npm executable location is included in your terminal PATH.
Ask for targeted help with finding the globally installed Neon CLI.

The CLI is ready to accept Neon commands. Next, you will use the anonymous claim flow to provision the database before signing up.

Create an Anonymous Neon Project

Your verified Neon CLI is ready to provision the database. The goal now is a live Postgres project before any Neon account exists.

Claimable Neon creates a bounded temporary project for an anonymous caller. The flow needs no account or payment details.

In this step, get ready to:

Provision an anonymous temporary Neon Postgres project from the terminal.
Locate the Postgres credentials for database access.
Locate the claim URL for later ownership transfer.

Create the anonymous project

An anonymous project supports short experiments before ownership transfer. Neon expires an unclaimed project after 72 hours.

Before you run the command, do you expect Neon to pause for an account login?

Create the temporary project by running this command:

neon claim create

What Does This Command Create?

The neon claim create command asks Claimable Neon to provision one project for an anonymous caller. Neon returns access to that project without an account login.

The returned database credentials support standard Postgres connections. The claim URL provides the later ownership handoff.

Confirm that the terminal reports a newly created temporary project.

The command should complete without opening an account login flow. Your terminal should show the newly provisioned project.

That is the unusual part working. Your database now exists before your Neon account does.

Project Creation Failed?

Confirm that the Neon CLI installation from the previous step remains available on your terminal path. Check your internet connection before retrying the command.

Ask for targeted help with diagnosing the anonymous project creation.

Read the handoff details

The command output carries the information needed to use the database. It also carries the link that transfers the project later.

Before you check the output, do you expect it to support both database access and later ownership transfer?

Confirm that the output shows the temporary project details.
Confirm that the output includes Postgres connection credentials.
Confirm that the output includes a claim URL for later ownership transfer.
Keep the terminal output available for the next step.
Hide the Postgres credentials before capturing your checkpoint.
Hide the claim URL before capturing your checkpoint.

You should now have a temporary project plus the credentials needed to connect to it. You should also have a claim URL that can transfer the project into a Neon account later.

Your account-free Postgres project is live. Next, you will pull its environment values into a local environment file.

Save Your Database Connection

Your anonymous Neon project is ready. However, its Postgres connection details still live in the terminal output from the previous step.

A local environment file gives your tools a stable place to find those details. You will save the generated values to .env before inspecting DATABASE_URL.

In this step, get ready to:

Pull the anonymous project's environment values into .env.
Inspect the saved DATABASE_URL connection string.

Pull the environment values

An environment variable gives a value a reusable name. DATABASE_URL stores the connection string that local database tools can read.

Save the generated Neon values to .env by running this command:

neon env pull --file .env

What Does This Command Do?

The neon env pull command retrieves the environment values for your temporary project.
The --file .env option writes those values to .env.
The generated file includes DATABASE_URL for connecting to Postgres.

That handoff is complete: .env now gives your local tools a stable path to the database.

Environment Pull Failed?

Confirm the anonymous project is still available from the claim flow.
Rerun the command in the terminal from earlier.

Ask for help with diagnosing the environment pull.

Inspect the saved connection

A Postgres connection string packages the details a client needs to reach one database. Inspecting its structure now confirms that the generated credential reached your local file.

Keep the Connection Private

The value assigned to DATABASE_URL includes a live database password. Anyone with the complete string can try to connect while that credential remains valid.

Keep the connection string on your own screen.
Redact every value before capturing a screenshot.

Before you open the file, do you expect the connection details to appear as separate settings or one URL?

Display the saved environment values by running this command:

cat .env

What Does This Command Do?

The cat command prints the contents of .env in your terminal.
The DATABASE_URL entry begins with postgresql://.
The URL identifies the database role.
The same URL includes the password.
The URL also identifies the Neon endpoint.
The final path identifies the database.

You should see a DATABASE_URL entry followed by the anonymous project's Postgres connection string. This proves the generated credential is available from .env.

Cannot Find DATABASE_URL?

Return to the folder where you ran the environment pull command.
Rerun the environment pull if .env is missing.
Check that the file contains a line beginning with DATABASE_URL=.

Ask for help with finding the saved connection string.

Your database connection is saved locally. Next, you will connect to Postgres and run your first queries.

Create and Query a Table

Your anonymous Neon project now has a connection string in .env. The next proof is data that remains available after each query finishes.

The database is still empty until it has a table. You will use SQL to define a small Postgres table. Two milestone rows will turn the empty database into something you can inspect.

In this step, get ready to:

Connect to the anonymous database through DATABASE_URL.
Create a table for project milestones.
Confirm two inserted milestones with a SELECT query.

Connect to the anonymous database

A connection string carries every detail psql needs to reach the database. DATABASE_URL keeps those details behind one environment variable.

Switch back to the terminal session from earlier.
Connect psql to the connection string in DATABASE_URL by running this command:

psql "$DATABASE_URL"

What Does This Command Do?

The psql client reads the connection URI from DATABASE_URL.
The client starts an interactive session against your anonymous database.

You should see a database prompt ready to accept SQL. You are connected. The anonymous project is accepting queries from your terminal.

Cannot Reach the Database?

Check that the current terminal session has DATABASE_URL loaded.
Load the existing value from .env if the variable is empty.
Confirm that you copied the complete connection string without adding spaces.

Ask for targeted help with diagnosing the database connection.

Create and populate the table

A relational table applies one column structure to every row. This structure keeps each project milestone predictable when you query it.

Create project_milestones by entering this SQL at the psql prompt:

-- Keep each milestone uniquely identifiable
CREATE TABLE project_milestones (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  milestone text NOT NULL,
  status text NOT NULL
);

What Does This SQL Do?

The id column gives each row a generated numeric key.
The milestone column stores the activity name.
The status column stores the current stage.

Confirm that psql reports successful table creation.

That structure is live in your anonymous database. It is ready to receive rows.

Table Creation Failed?

Check that every column definition ends with a comma except the final one.
Confirm that the closing parenthesis appears before the final semicolon.

Ask for help with fixing the table statement.

The table now has a shape but no records. An INSERT statement adds each milestone as a row.

Insert two project milestones by entering this SQL at the psql prompt:

-- Add two milestones that show the project's current state
INSERT INTO project_milestones (milestone, status)
VALUES
  ('Provision database', 'done'),
  ('Claim project', 'next');

What Does This SQL Do?

The column list maps each supplied value to its destination.
The VALUES section adds two rows in one statement.
The database generates each id value automatically.

Confirm that psql reports two inserted rows.

Your database now holds real records. The next query proves that the values were stored.

Rows Were Not Inserted?

Check that every text value has matching single quotes.
Confirm that each row contains one milestone value plus one status value.
Verify that the table name is project_milestones.

Ask for targeted help with repairing the insert statement.

Select the stored rows

A SELECT query reads columns from stored rows. Sorting by id keeps the result in insertion order.

Before you run the query, which two milestones do you expect to see?

Read the stored milestones by entering this SQL at the psql prompt:

-- Read every stored milestone in insertion order
SELECT id, milestone, status
FROM project_milestones
ORDER BY id;

What Does This Query Do?

The query returns the generated key plus both text columns.
The FROM clause reads from project_milestones.
The ORDER BY clause places the lower generated key first.

You should see two rows. The first contains Provision database with done.

The second row contains Claim project with next. You have closed the loop from an anonymous connection string to stored Postgres data.

Query Returned No Rows?

Confirm that the earlier insert reported two accepted rows.
Check that the query reads from project_milestones.
Rerun the insert statement if the table is empty.

Ask for help with tracing the missing rows.

Your rows are stored in the anonymous database. Next, you will read the same data over HTTP without using a Postgres client.

Read Your Data Over HTTP

The rows you selected through Postgres prove that your temporary database stores real data. Applications need another path that works outside an interactive database client.

This step uses HTTP through the Neon serverless driver. A small Node.js script reads your existing connection string before displaying the same stored rows.

In this step, get ready to:

Install the HTTP database driver.
Create a script that reads DATABASE_URL from .env.
Display the stored rows without an interactive Postgres client.

Install the HTTP driver

The serverless driver turns a connection string into a query function that sends one-shot database requests over HTTP. The dotenv package loads your existing .env values into the script.

Why HTTP for this query?

HTTP suits an independent read query because each request can complete without an ongoing database session. This pattern works in application environments where a raw Postgres connection is unavailable.

Your earlier Postgres client proved that the database accepts direct connections. This script proves that application code can reach the same data through another transport.

Return to the terminal session in the folder that contains .env.
Install the HTTP driver and environment loader by running this command:

npm install @neondatabase/serverless dotenv

What Does This Command Do?

The command adds @neondatabase/serverless for HTTP database queries. It also adds dotenv so Node.js can load DATABASE_URL from .env.

The installation output should end with a completion summary. Your folder now has the packages needed for the HTTP read.

Dependency Installation Failed?

Confirm that the terminal is in the folder containing .env.
Check your internet connection before retrying the installation.
Ask for help with diagnosing the dependency installation.

Create the HTTP query script

The script reads the connection credential from .env. Your connection string stays outside the source file.

Record the exact table name from your earlier SQL exercise here: your Postgres table name.
Create http-query.mjs beside .env with your editor's New File control.
Configure the HTTP read by pasting the following code into http-query.mjs:

import 'dotenv/config';
import { neon } from '@neondatabase/serverless';

// Stop before connecting if the local credential was not loaded.
if (!process.env.DATABASE_URL) {
  throw new Error('DATABASE_URL is missing from .env');
}

// Create the function that sends one-shot queries over HTTP.
const sql = neon(process.env.DATABASE_URL);

// Keep the identifier limited to the table created in the SQL exercise.
const tableName = '[[TABLE_NAME="your Postgres table name"]]';

// Read every stored column from the trusted table identifier.
const rows = await sql`SELECT * FROM ${sql.unsafe(tableName)}`;

// Display the returned objects as a readable terminal table.
console.log(`Rows from ${tableName}:`);
console.table(rows);

What Does This Code Do?

The dotenv/config import loads values from .env into the running process.
The neon() function creates an HTTP query function from DATABASE_URL.
The sql.unsafe() helper inserts the table name as a trusted SQL identifier. Keep this value limited to the table you created.
The console.table() call displays each returned row with its column names.

Save http-query.mjs.

✔️ Awesome, I've got everything!

Your HTTP query script is complete. Its connection credential remains in the existing .env file.

ⓧ I'd like to double check the full code

import 'dotenv/config';
import { neon } from '@neondatabase/serverless';

// Stop before connecting if the local credential was not loaded.
if (!process.env.DATABASE_URL) {
  throw new Error('DATABASE_URL is missing from .env');
}

// Create the function that sends one-shot queries over HTTP.
const sql = neon(process.env.DATABASE_URL);

// Keep the identifier limited to the table created in the SQL exercise.
const tableName = '[[TABLE_NAME="your Postgres table name"]]';

// Read every stored column from the trusted table identifier.
const rows = await sql`SELECT * FROM ${sql.unsafe(tableName)}`;

// Display the returned objects as a readable terminal table.
console.log(`Rows from ${tableName}:`);
console.table(rows);

Run the query over HTTP

Before you run the script, do you expect the returned values to match the rows you selected through your Postgres client?

Send the HTTP query by running this command:

node http-query.mjs

What Does This Command Do?

The node command executes http-query.mjs as an ECMAScript module. The script loads DATABASE_URL before sending the SELECT query over HTTP.

You should see a heading containing your table name. Below it you should see the same stored rows with their column values.

That closes the loop. The same stored rows now arrive through an HTTP request.

Rows Did Not Appear?

Confirm that http-query.mjs sits beside the existing .env file.
Check that your saved table name matches the identifier used in the earlier SQL exercise.
Confirm that DATABASE_URL remains present in .env without displaying its value.
Ask for help with troubleshooting the HTTP query.

Keep .env closed while capturing your result.

Your temporary database now serves the same data through Postgres and HTTP. Next, you will use the claim link to transfer the project into your Neon account.

Claim Your Neon Project

Your anonymous Neon project has already proved it can hold real Postgres data. Your HTTP query displayed the same stored rows.

The database still belongs to the anonymous claim flow. You will transfer it into your account. Then you will confirm that the project stays intact.

In this step, get ready to:

Open the claim URL.
Authenticate with a Neon account.
Claim the anonymous project.

Open the claim link

The claim URL can disappear inside a busy terminal history. It sits in the output from the earlier claim-create flow beside your temporary project details.

Switch back to the terminal output from the Neon CLI claim-create flow.
Locate the claim URL printed with the temporary project details.
Open the claim URL in your web browser.

You should see a claim page that asks you to continue with a Neon account. This page links the temporary project to a human owner.

Choose the tab that matches your current account status.

I already have a Neon account

Your existing account gives the temporary project an ownership destination.

Use the sign-in path shown on the claim page.
Complete authentication with your Neon account.
Return to the original claim page if your browser does not return automatically.

You are through the account gate. The claim page can now attach the project to your account.

I need a Neon account

A new Neon account can receive the temporary project immediately after authentication.

Use the account-creation path shown on the claim page.
Complete the requested account details.
Finish any verification request that Neon presents.
Return to the original claim page if your browser does not return automatically.

Your account is ready to receive the project. The anonymous database now has a destination owner.

Authentication Stopped?

Return to the original claim URL if authentication leaves you on another page.
Check that your browser permits the authentication page to return to Neon.
Retry the account flow in the same browser window.

Ask for targeted help with completing the Neon claim authentication.

Accept the project transfer

Claiming assigns the temporary project to the account you just authenticated. The project keeps its existing database contents.

What Does Claiming Change?

The transfer changes the owner recorded for the project. Your existing database remains attached to that project.

The connection credentials remain available after the claim. Your local environment can continue using the same connection string.

This handoff changes ownership, so taking a moment to check the destination is worthwhile. Review the account details shown by Neon before you confirm.

Review the destination account or organization shown on the confirmation page.
Confirm that the displayed destination is the account you intend to use.
Accept the project transfer using the confirmation control on the page.

The browser should complete the transfer before taking you to the Neon dashboard. The project now belongs to your signed-in account.

That is the handoff complete: the database you created without an account now belongs to you.

Transfer Did Not Finish?

Return to the original claim URL in the same browser session.
Confirm that you are authenticated with the intended Neon account.
Retry the transfer confirmation from the claim page.

Ask for targeted help with finishing the Neon project transfer.

Verify the claimed project

The dashboard confirms that your account owns the project. Your existing HTTP query confirms that the database contents survived the handoff.

Before you check, which project do you expect to find in the account?

Open the project list for the destination account from the Neon dashboard.
Find the project whose details match the temporary project you created earlier.

You should see the claimed project in the dashboard. Its presence proves that the anonymous project transferred into your account.

Switch back to the HTTP database query from the previous step.
Run or refresh the query using the same method as before.

You should see the same stored rows again. The existing .env file still supplies the claimed project's connection string.

You closed the loop: the same database now responds from a project you own.

Close any dashboard panel that displays the full connection string before capturing your result.

Secret mission

Prove Cross-Connection Data Consistency

Compare the claimed database through your Postgres client. Check the same rows through your HTTP query. Capture evidence that both paths still reach the same Neon project.

Clean Up Your Resources

Your anonymous database now belongs to your Neon account. The anonymous provisioning cost $0, but the claimed project now follows your Neon account plan.

Cost warning

Keeping the claimed project may use your account allowance or create charges under your Neon plan. Choose the delete option if you no longer need the database.

Resources you used:

The claimed Neon Postgres project that contains your table plus its inserted rows.
The local .env file that contains DATABASE_URL.
The local HTTP-capable script or page that displays the same database rows.

Keep everything running

No action is needed. Choose this if you want to continue querying the claimed database.

Keep the claimed Neon Postgres project in your account.
Keep the local .env file in its current location.
Keep the HTTP-capable script or page for future database queries.

Your table remains available through the existing connection string. The HTTP flow can still display its rows.

Pause - I'll come back to this later

Stop local database activity while preserving the claimed project for later. The project remains subject to your Neon account plan.

Close any active Postgres client session.
Stop any local process that runs the HTTP-capable script or page.
Keep the .env file in its current location.
Keep the claimed Neon project in your account.

Local queries stop. Your table plus its rows remain stored in the claimed project.

Delete - I don't want to use this again

Remove the claimed database plus the local files when you are finished. Deleting the project permanently removes its table plus rows.

Return to the Neon dashboard from earlier.
Select the claimed Postgres project.
Open the settings for that project.
Use the project deletion control in those settings.
Complete the requested deletion confirmation.
Return to the project list.

The claimed project no longer appears in your Neon dashboard. Its table plus stored rows are also removed.

Use Finder on macOS or File Explorer on Windows to return to the location containing .env.
Delete the local .env file.
Return to the location containing the HTTP-capable script or page.
Delete the HTTP-capable script or page.
Confirm that both local resources no longer appear in their previous locations.

Your database credentials plus the local HTTP query are now removed from your computer.

Nice Work!

You pulled it off! A live Neon Postgres database existed before your account did.

What you can now do:

Use the Neon CLI for anonymous database provisioning before creating an account.
Load DATABASE_URL from .env for a complete data workflow. Create a table. Insert rows. Select them back.
Read the stored rows through an HTTP connection. Transfer ownership by claiming the project. Confirm the claimed database in the Neon dashboard.
Secret Mission: Take on an optional challenge that extends your claimed database workflow.

Ready to quiz yourself?