If you're already signed up or coming to Neon from **Azure**, you can skip ahead to [Step 2](https://neon.com/docs/get-started/signing-up#step-2-onboarding-in-the-neon-console).
If you haven't signed up yet, you can sign up for free here:
[https://console.neon.tech/signup](https://console.neon.tech/signup)
Sign up with your email, GitHub, Google, or other partner account.
For information about what's included with the Free and paid plans, see
[Neon plans](https://neon.com/docs/introduction/plans).
## Onboarding in the Neon Console
After you sign up, you are guided through some onboarding steps that ask you to create a **Project**.
The steps should be self-explanatory, but it's important to understand a few key points:
- **In Neon, everything starts with the _Project_**
It is the top-level container that holds your branches, databases, and roles. Typically, you should create a project for each repository in your application. This allows you to manage your database branches just like you manage your code branches: a branch for production, staging, development, new features, previews, and so forth.
- **We create two branches for you**
- `production` is the default (primary) branch and hosts your database, role, and a compute that you can connect your application to
- `development` is created as a child branch of production for your development work
At this point, if you want to just get started connecting Neon to your toolchain, go to [Day 2 - Connecting Neon to your tools](https://neon.com/docs/get-started/connect-neon). Or if you want a more detailed walkthrough of some of our key console and branching features, let's keep going.
## Add sample data
Let's get familiar with the **SQL Editor**, where you can run queries against your databases directly from the Neon Console, as well as access more advanced features like [Time Travel](https://neon.com/docs/guides/time-travel-assist) and [Explain and Analyze](https://neon.com/docs/get-started/query-with-neon-sql-editor#explain-and-analyze).
From the Neon Console, use the sidebar navigation to open the **SQL Editor** page. Notice that your default branch `production` is already selected, along with the database created during onboarding, `neondb`.
The first time you open the SQL Editor for a new project, the editor includes placeholder SQL commands to create and populate a new sample table called `playing_with_neon`.
For this tutorial, go ahead and create this sample table: click **Run**.
Every query you run in the SQL Editor is automatically saved with an AI-generated description, making it easy to find and reference your work later. For example, the sample table creation above will be saved with a description like "create and populate sample table in Neon". You can view your query history anytime by clicking the **History** button in the SQL Editor.
Or if you want to add the table from the command line and you already have `psql` installed:
```sql
CREATE TABLE IF NOT EXISTS playing_with_neon(id SERIAL PRIMARY KEY, name TEXT NOT NULL, value REAL);
INSERT INTO playing_with_neon(name, value)
SELECT LEFT(md5(i::TEXT), 10), random() FROM generate_series(1, 10) s(i);
```
Your default branch `production` now has a table with some data.
## Try the AI Assistant
Now that you have some sample data, let's explore how the AI Assistant can help you write SQL queries using natural language prompts.
From the SQL Editor, click the **AI Assistant** button in the top-right corner and try a few prompts:
- _Add three more rows to the playing_with_neon table with tech company names_
- _Show me the highest value in the table_
- _Calculate the average value grouped by the first letter of the name_
Each query you run is automatically saved with an AI-generated description, making it easy to find and reuse queries later. For example, when you ask the AI Assistant to add company data, you should see a response like:
```sql
-- Text to SQL original prompt:
-- Add three more rows to the playing_with_neon table with tech company names
INSERT INTO public.playing_with_neon (name, value) VALUES
('Google', 1000.5),
('Apple', 1200.75),
('Microsoft', 950.25);
```
With the description: "Add tech companies to playing_with_neon table"
Learn more about AI features in the [SQL Editor documentation](https://neon.com/docs/get-started/query-with-neon-sql-editor#ai-features).
## View and modify data in the console
Now that you have some data to play with, let's take a look at it on the **Tables** page in the Neon Console. The **Tables** page, powered by [Drizzle Studio](https://orm.drizzle.team/drizzle-studio/overview), provides a visual interface for exploring and modifying data directly from the console. The integration with Drizzle Studio provides the ability to add, update, and delete records, filter data, add or remove columns, drop or truncate tables, and export data in `.json` and `.csv` formats.
For a detailed guide on how to interact with your data using the **Tables** page, visit [Managing your data with interactive tables](https://neon.com/docs/guides/tables).
## Working with your development branch
Your project comes with a `development` branch that's an isolated copy of your `production` branch. Let's learn how to use the Neon CLI to manage branches and make some schema changes in your development environment.
1. **Install CLI with Brew or NPM**
Depending on your system, you can install the Neon CLI using either Homebrew (for macOS) or NPM (for other platforms).
- For macOS using Homebrew:
```bash
brew install neonctl
```
- Using NPM (applicable for all platforms that support Node.js):
```bash
npm install -g neonctl
```
2. **Authenticate with Neon**
The `neon auth` command launches a browser window where you can authorize the Neon CLI to access your Neon account.
```bash
neon auth
```
3. **View your branches**
```bash
neon branches list
```
This command shows your existing branches, including the `production` and `development` branches.
## Make some sample schema changes
First, let's make sure our development branch is in sync with production. This ensures we're starting from the same baseline:
```bash
neon branches reset development --parent
```
Now that our development branch matches production, we can make some changes. The `playing_with_neon` table from production is now available in your `development` branch, and we'll modify its schema and add new data to demonstrate how branches can diverge.
You can use the [Neon SQL Editor](https://neon.com/docs/get-started/query-with-neon-sql-editor) for this, but let's demonstrate how to connect and modify your database from the terminal using `psql`. If you don't have `psql` installed already, follow these steps to get set up:
Tab: Mac
```bash
brew install libpq
echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
```
Tab: Linux
```bash
sudo apt update
sudo apt install postgresql-client
```
Tab: Windows
Download and install PostgreSQL from:
https://www.postgresql.org/download/windows/
Ensure psql is included in the installation.
With `psql` available, let's work from the terminal to connect to your `development` branch's database and make changes.
1. **Connect to your database**
Get the connection string to your branch and connect to it directly via `psql`:
```bash
neon connection-string development --database-name neondb --psql
```
This command establishes the psql terminal connection to the `neondb` database on your development branch.
1. **Modify the schema**
Add a new column `description` and index it:
```sql
ALTER TABLE playing_with_neon
ADD COLUMN description TEXT;
CREATE INDEX idx_playing_with_neon_description ON playing_with_neon (description);
```
1. **Insert new data**
Add new data that will be exclusive to the dev branch.
```sql
INSERT INTO playing_with_neon (name, description)
VALUES ('Your dev branch', 'Exploring schema changes in the dev branch');
```
1. **Verify the schema changes**
Query the table to verify your schema changes:
```sql
SELECT * FROM playing_with_neon;
```
Your response should include the new description column and a new row where name = `Your dev branch` and description = `Exploring schema changes in the dev branch`:
```sql {1,13}
id | name | value | description
----+--------------------+-------------+--------------------------------------------
1 | c4ca4238a0 | 0.5315024 |
2 | c81e728d9d | 0.17189825 |
3 | eccbc87e4b | 0.21428405 |
4 | a87ff679a2 | 0.9721639 |
5 | e4da3b7fbb | 0.8649301 |
6 | 1679091c5a | 0.48413596 |
7 | 8f14e45fce | 0.82630277 |
8 | c9f0f895fb | 0.99945337 |
9 | 45c48cce2e | 0.054623786 |
10 | d3d9446802 | 0.36634886 |
11 | Your dev branch | | Exploring schema changes in the dev branch
(11 rows)
```
## Check your changes with Schema Diff
After making the schema changes to your development branch, you can use the [Schema Diff](https://neon.com/docs/guides/schema-diff) feature to compare your branch against its parent branch. Schema Diff is a GitHub-style code-comparison tool used to visualize differences between different branch's databases.
For this tutorial, Schema Diff helps with validating isolation: it confirms that schema changes made in your isolated development branch remain separate from the production branch.
From the **Branches** page in the Neon Console:
1. Open the detailed view for your `development` branch and click **Open schema diff**.
2. Verify the right branches are selected and click **Compare**. You can see the schema changes we added to our development branch highlighted in green.
### Schema Migrations
A more typical scenario for Schema Diff is when preparing for schema migrations. While Neon does not provide built-in schema migration tools, you can use ORMs like [Drizzle](https://drizzle.team/) or [Prisma](https://www.prisma.io/) to handle schema migrations efficiently. Read more about using Neon in your development workflow in [Connect Neon to your stack](https://neon.com/docs/get-started/connect-neon).
## Reset your development branch to production
After experimenting with changes in your development branch, let's now reset the branch to `production`, its parent branch.
[Branch reset](https://neon.com/docs/guides/reset-from-parent) functions much like a `git reset –hard parent` in traditional Git workflows.
Resetting your development branches to your production branch ensures that all changes are discarded, and your branch reflects the latest stable state of `production`. This is key to maintaining a clean slate for new development tasks and is one of the core advantages of Neon's branching capabilities.
You can reset to parent from the **Branches** page of the Neon Console, but here we'll use the Neon CLI.
Use the following command to reset your `development` branch to the state of the `production` branch:
Example:
```bash
neon branches reset development --parent
```
If you go back to your **Schema Diff** and compare branches again, you'll see they are now identical:
### When to reset your branch
Depending on your development workflow, you can use branch reset:
- **After a feature is completed and merged**
Once your changes are merged into `production`, reset the development branch to start on the next feature.
- **When you need to abandon changes**
If a project direction changes or if experimental changes are no longer needed, resetting the branch quickly reverts to a known good state.
- **As part of your CI/CD automation**
With the Neon CLI, you can include branch reset as an enforced part of your CI/CD automation, automatically resetting a branch when a feature is closed or started.
Make sure that your development team is always working from the latest schema and data by including branch reset in your workflow. To read more about using branching in your workflows, see [Day 3 - Branching workflows](https://neon.com/docs/get-started/workflow-primer).
**Tip** working with sensitive data?: Neon also supports schema-only branching. [Learn more](https://neon.com/docs/guides/branching-schema-only).
---
# Source: https://neon.com/llms/get-started-why-neon.txt
# Why Neon?
> The document "Why Neon?" outlines the key features and advantages of using Neon, a cloud-native Postgres database service, emphasizing its scalability, cost-efficiency, and developer-friendly architecture tailored for modern applications.
## Source
- [Why Neon? HTML](https://neon.com/docs/get-started/why-neon): The original HTML version of this documentation
Looking back at Neon's debut blog post, [SELECT 'Hello, World'](https://neon.com/blog/hello-world), the fundamental reasons for **Why Neon** remain the same:
- **To build the best Postgres experience in the cloud**
This is still our core mission today. It was clear to us then, as it is now, that database workloads are shifting to the cloud — and no one wants to manage a database themselves.
- **In an ever-changing technology stack, we believe Postgres is here to stay**
Just like the Linux operating system or Git version control, we believe Postgres is the default choice for a relational database system. That's why all of the major platforms like AWS, Azure, Google Cloud, Digital Ocean, and many newcomers to this space offer Postgres as a service.
- **An idea that a modern Postgres cloud service can be designed differently**
We call this approach _separation of storage and compute_, which lets us architect the service around performance, reliability, manageability, and cost-efficiency.
- **The belief that our architecture can provide a better Developer Experience (DevX)**
Features such as autoscaling, branching, time travel, instant provisioning, and instant restore improve the developer experience by allowing quick environment setup, efficient developer workflows, and immediate database availability.
These are Neon's reasons, but given the many _database-as-a-service_ options available today, let's take a look at the reasons why **you** should choose Neon:
## Neon is Postgres
**Postgres is the world's most popular open-source database.**
From its beginning as a [DARPA-sponsored project at Berkeley](https://www.postgresql.org/docs/current/history.html), Postgres has fostered an ever-growing community and is a preferred database among developers because of its performance, reliability, extensibility, and support for features like ACID transactions, advanced SQL, and NoSQL/JSON. Neon supports all of the latest Postgres versions and numerous [Postgres extensions](https://neon.com/docs/extensions/pg-extensions).
**If your application runs on Postgres, it runs on Neon**. If it doesn't run on Postgres, [sign up](https://console.neon.tech/signup) for a Free plan account, join our [Discord server](https://discord.gg/92vNTzKDGp), and start the journey with us.
## Neon is serverless
**A serverless architecture built for performance, reliability, manageability, and cost efficiency**
Neon's [architecture](https://neon.com/docs/introduction/architecture-overview) separates compute from storage, which enables serverless features like instant provisioning, [autoscaling](https://neon.com/docs/get-started/production-readiness#autoscaling), [scale to zero](https://neon.com/docs/get-started/production-readiness#scale-to-zero), and more.
Separating compute from storage refers to an architecture where the database computation processes (queries, transactions, etc.) are handled by one set of resources (compute), while the data itself is stored on a separate set of resources (storage). This design contrasts with traditional architectures where compute and storage are tightly coupled on the same server. In Neon, Postgres runs on a compute, and data (except for what's cached in local compute memory) resides on Neon's storage layer.
Separation of compute and storage allows these resources to be scaled independently. You can adjust for processing power or storage capacity as needed without affecting the other. This approach is also cost-efficient. The ability to scale resources independently means you can benefit from the lower cost of storage compared to compute or avoid paying for additional storage when you only require extra processing power. Decoupling compute and storage also improves availability and durability, as data remains accessible and safe, even if a compute fails.
[Read more about the benefits of Neon's serverless architecture](https://neon.com/docs/introduction/serverless) and how it supports database-per-user architectures, variable workloads, database branching workflows, and [AI agents](https://neon.com/use-cases/ai-agents).
**Tip** Did you know?: Neon's autoscaling feature instantly scales your compute and memory resources. **No manual intervention or restarts are required.**
## Neon is fully managed
**Leave the database administrative, maintenance, and scaling burdens to us.**
Being a fully managed service means that Neon provides high availability without requiring users to handle administrative, maintenance, or scaling burdens associated with managing a database system. This approach allows developers to focus more on developing applications and less on the operational aspects of database management. Neon takes care of the complexities of scaling, backups, maintenance, and ensuring availability, enabling developers to manage their data without worrying about the underlying infrastructure.
## Neon is open source
**Neon is developed under an Apache 2.0 license.**
Neon offers separation of storage and compute for Postgres, providing a modern, cloud-native approach to database architecture.
We believe we have an opportunity to define the standard for cloud Postgres. We carefully designed our storage, focusing on cloud independence, performance, manageability, DevX, and cost. We chose the most permissive open-source license, Apache 2.0, and invited the world to participate. You can already build and run your own self-hosted instance of Neon. Check out our [neon GitHub repository](https://github.com/neondatabase) and the [#self-hosted](https://discord.com/channels/1176467419317940276/1184894814769127464) channel on our Discord server.
## Neon doesn't lock you in
**As a true Postgres platform, there's no lock-in with Neon.**
Building on Neon is building on Postgres. If you are already running Postgres, getting started is easy. [Import your data](https://neon.com/docs/import/import-intro) and [connect](https://neon.com/docs/connect/connect-intro). Migrating from other databases like MySQL or MongoDB is just as easy.
If you need to move data, you won't have to tear apart your application to remove proprietary application layers. Neon is pro-ecosystem and pro-integration. We encourage you to build with the frameworks, platforms, and services that best fit your requirements. Neon works to enable that. Check out our ever-expanding collection of [framework](https://neon.com/docs/get-started/frameworks), [language](https://neon.com/docs/get-started/languages), and [integration](https://neon.com/docs/guides/integrations) guides.
## Who should use Neon?
**You. And we're ready to help you get started.**
Neon is designed for a wide range of users, from individual developers to enterprises, seeking modern, serverless Postgres capabilities. It caters to those who need a fully managed, scalable, and cost-effective database solution. Key users include:
- **Individual developers** looking for a fast and easy way to set up a Postgres database without the hassle of installation or configuration. Neon's Free plan makes it easy to get started. [Free plan](https://neon.com/docs/introduction/plans) users get access to all regions and features like connection pooling and branching. When you are ready to scale, you can easily upgrade your account to a paid plan for more computing power, storage, and advanced features.
**Tip** Neon's Free plan is here to stay: Neon's Free plan is a fundamental part of our commitment to users. Our architecture, which separates storage and compute, enables a sustainable Free plan. You can build your personal project or PoC with confidence, knowing that our Free plan is here to stay. [Learn more about our Free plan from Neon's CEO](https://twitter.com/nikitabase/status/1758639571414446415).
- **Teams and organizations** that aim to enhance their development workflows with the ability to create database branches for testing new features or updates, mirroring the branching process used in code version control.
- **Enterprises** requiring scalable, high-performance database solutions with advanced features like autoscaling, scale to zero, instant restore, and logical replication. Enterprises can benefit from custom pricing, higher resource allowances, and enterprise-level support to meet their specific requirements.
- **AI agents** that need to rapidly provision Postgres databases, execute SQL queries, and efficiently manage Neon infrastructure. With one-second provision times, scale-to-zero compute, and agent-friendly client interfaces, Neon enables AI agents to manage database fleets at scale while keeping costs low. AI agents are on track to surpass humans in the number of databases created on the Neon platform. [Learn more about this use case](https://neon.com/use-cases/ai-agents).
In summary, Neon is built for anyone who requires a Postgres database and wants to benefit from the scalability, ease of use, cost savings, and advanced DevX capabilities provided by Neon's serverless architecture.
## Neon makes it easy to get started with Postgres
**Set up your Postgres database in seconds.**
1. [Log in](https://console.neon.tech/signup) with an email address, Google, or GitHub account.
2. Provide a project name and database name, and select a region.
3. Click **Create Project**.
Neon's architecture allows us to spin up a Postgres database almost instantly and provide you with a database URL, which you can plug into your application or database client.
```sql
postgresql://alex:AbC123dEf@ep-cool-darkness-123456.us-east-2.aws.neon.tech/dbname?sslmode=require&channel_binding=require
```
Additionally, after signing up, we land you on your project dashboard, where you'll find connection snippets for various frameworks, languages, and platforms.
If you are not quite ready to hook up an application, you can explore Neon from the console. Create the `playing_with_neon` table using the Neon [SQL Editor](https://neon.com/docs/get-started/query-with-neon-sql-editor), run some queries, or create a database branch.
Initially, you'll be signed up for Neon's [Free plan](https://neon.com/docs/introduction/plans), but you can easily upgrade to one of our paid plans when you're ready.
---
# Source: https://neon.com/llms/get-started-workflow-primer.txt
# Database branching workflow primer
> The "Database Branching Workflow Primer" document outlines the process for creating and managing database branches in Neon, enabling users to efficiently handle development and testing environments.
## Source
- [Database branching workflow primer HTML](https://neon.com/docs/get-started/workflow-primer): The original HTML version of this documentation
With Neon, you can work with your data just like you work with your code. The key is Neon's database [branching](https://neon.com/docs/guides/branching-intro) feature, which lets you instantly create branches of your data that you can include in your workflow — as many branches as you need.
Neon branches are:
- **Isolated**: changes made to a branch don't affect its parent.
- **Fast to create**: creating a branch takes ~1 second, regardless of the size of your database.
- **Cost-effective**: you're only billed for unique data across all branches, and they scale to zero when not in use (you can configure this behavior for every branch).
- **Ready to use**: branches will have the parent branch's schema and all its data (you can also include data up to a certain point in time). If you're working with sensitive data, Neon also supports a [schema-only branching](https://neon.com/docs/guides/branching-schema-only) option.
Every Neon branch has a unique Postgres connection string, so they're completely isolated from one another.
```bash
# Branch 1
postgresql://database_name_owner:AbC123dEf@ep-shiny-cell-a5y2zuu0.us-east-2.aws.neon.tech/dbname?sslmode=require&channel_binding=require
# Branch 2
postgresql://database_name_owner:AbC123dEf@ep-hidden-hall-a5x58cuv.us-east-2.aws.neon.tech/dbname?sslmode=require&channel_binding=require
```
You can create all of your branches from the default branch, or set up a dedicated branch that you use as a base. The first approach is simpler, while the second provides greater data isolation.
## Create branch methods
You can use either the Neon CLI or GitHub actions to incorporate branching into your workflow.
### Neon CLI
Using the [Neon CLI](https://neon.com/docs/reference/neon-cli), you can create branches without leaving your editor or automate branch creation in your CI/CD pipeline.
And here are the key CLI actions you can use:
```bash
# Create branch
neon branches create [options]
# Get Connection string
neon connection-string [branch] [options]
# Delete branch
neon branches delete