# Elements vs Neon

Neon is a serverless Postgres host: a company that runs Postgres databases in the cloud and bills them by use. [Databricks acquired Neon in 2025](https://www.techtarget.com/searchdatamanagement/news/366623864/Databricks-adds-Postgres-database-with-1B-Neon-acquisition), and Neon now describes itself as ["a complete backend from Databricks"](https://neon.com/). Neon separates storage from compute, so a database's data lives in Neon's storage layer while the Postgres server that runs queries, called a compute, starts and stops on its own. A compute [autoscales](https://neon.com/docs/introduction/autoscaling) between sizes you set and [scales to zero](https://neon.com/docs/introduction/scale-to-zero) after five minutes of inactivity. [Branching](https://neon.com/docs/introduction/branching) makes an instant copy-on-write clone of a database, with its data and schema, that you can change or delete without touching the original, and instant restore brings a database back to an earlier moment. Around Postgres, Neon offers managed sign-in built on Better Auth, a Data API generated from your tables, Functions, object storage and an AI gateway. [Pricing](https://neon.com/pricing) has a Free plan and two paid plans, Launch and Scale, that bill compute by the hour and storage by the gigabyte-month, with no monthly minimum.

Elements is not a database company. It is an integrated app environment for building web apps, built for people and their agents: one coherent system that includes a project server that runs while you work, a default app framework, a package installer, a test runner, a bundled Postgres database, and deploy. Elements runs its bundled Postgres on your machine while you develop and on the server you deploy to, and it connects to any hosted Postgres, Neon included, through `DB_HOST` ([hosted Postgres](/learn/man/database/cli)). It deploys to any Ubuntu server you reach over SSH, charges for its tooling per machine, and meters nothing ([pricing](/pricing)).

Neon and Elements fit together through configuration alone. An Elements app points `DB_HOST` at a Neon database, connects over TLS, creates its app and test databases, and runs unchanged. Neon's sign-in, Data API and Functions do jobs an Elements app already does itself, so with Elements, Neon does one job: running Postgres. Branching is the reason to choose it for that job: a copy of production for staging or review, created instantly.

## Connecting an Elements App to Neon

Elements bundles Postgres, and a deploy machine runs its own copy by default, a good fit for a prototype or a single-server app. For several machines, or when you want backups and scaling run for you, Elements recommends a hosted Postgres, and Neon is one. To use Neon, put its connection details in the environment's env file ([deploy setup](/learn/man/deploy/setup)):

```bash
# config/env/production.env
DB_HOST=ep-cool-darkness-123456.us-east-2.aws.neon.tech
DB_PORT=5432
DB_USER=...
DB_PASSWORD=...
DB_DEFAULT=neondb
```

Use the compute's direct hostname, the one without `-pooler` in it. Elements connects over TLS to any host other than your own machine, so there is no `sslmode` to set. On the first build against the environment, it creates the app database and its test database on the Neon branch. To create them, it first connects to an existing database, and `DB_DEFAULT` names it: a new Neon project comes with a database called [`neondb`](https://neon.com/docs/manage/databases). Roles created in Neon's console belong to [`neon_superuser`](https://neon.com/docs/manage/roles), which can create databases ([hosted Postgres](/learn/man/database/cli)).

Neon runs Postgres 14 through 18 ([compatibility](https://neon.com/docs/reference/compatibility)). Elements needs Postgres 16 or newer, so pick 16, 17 or 18 when you create the project.

## Use the Direct Connection, Not the Pooler

Neon offers two connection strings for every compute. The pooled one, with `-pooler` in the hostname, goes through PgBouncer in [transaction mode](https://neon.com/docs/connect/connection-pooling), which returns a connection to the pool after each transaction. Neon lists what that mode does not support, and `LISTEN` / `NOTIFY` is on the list.

Elements relies on `LISTEN`/`NOTIFY`. Channels, which push messages from the server to open browsers, run on it, and every app server keeps a listening connection open ([channel](/learn/man/channel)). LiveTable, the live set of rows that stays in sync in every browser, opens a `LISTEN` before it reads its rows ([livetable](/learn/man/livetable/options)). Both need a connection that stays open for the life of the app, and the direct connection does.

A pooler serves clients that open many short-lived connections, such as serverless functions. An Elements app is a long-running server that holds its own connection pool, so it does not need one. A 1 CU Neon compute accepts [419 direct connections](https://neon.com/docs/connect/connection-pooling), far more than an app server's pool uses.

## Production Runs Always On. Branches Scale to Zero.

Scale to zero is central to Neon's pricing. When a compute has been inactive for five minutes, Neon suspends it, stops billing its compute, and starts it again on the next connection, which Neon says takes ["a few hundred milliseconds"](https://neon.com/docs/introduction/scale-to-zero). The Free plan always scales to zero; on paid plans you can turn it off.

An Elements app keeps its database busy around the clock. Every app server holds a listening connection for channels and LiveTable, and cron schedules run on the app's elected leader process ([jobs](/learn/man/jobs)). Neon's own cost guide says that ["applications that maintain long-lived connections or scheduled jobs (like cron tasks) can prevent your compute from scaling to zero, keeping it active 24/7."](https://neon.com/docs/introduction/cost-optimization)

For production, turn scale to zero off and size the compute to run all the time. Scale to zero pays off for databases with no app attached, such as a branch you open to try a migration or review a change, and it is why a Neon project can hold many of them cheaply.

## Branching Gives Staging a Copy of Production

A Neon branch is ["a copy-on-write clone of your data"](https://neon.com/docs/introduction/branching), created instantly, and creating one "does not increase load on the parent branch." Each branch gets its own compute and its own hostname, you can [branch from a past point in time](https://neon.com/docs/manage/branches) within your history window, and "Reset from parent" brings a branch up to date with production in one step.

Branches pair with Elements environments. A staging environment is a second server and a second env file, deployed with `elements deploy staging` ([environments](/learn/man/deploy/environments)). Point staging's `DB_HOST` at a branch of your production database, reset it from production before a deploy, and staging runs against a copy of real data. Every Elements deploy already runs pending migrations against the test database, then runs the tests, and only then migrates the app database ([what deploy does](/learn/man/deploy/what-happens)). Each batch of migrations applies in one transaction, in full or not at all ([migrations](/learn/man/migrations)). A branch adds a rehearsal of that migration against production's data, on staging, before production ever sees it.

## Neon's Other Services Are Already in Your App

Neon's sign-in, Data API, Functions and object storage give a frontend with no server of its own a backend to call. An Elements app has its own server, and the same jobs are part of its framework, written in TypeScript and deployed with the rest of the app:

- **Sign-in and sessions.** Sessions are built into the framework, and a sign-in form calls a server function that checks the password and calls `session.login()` ([session](/learn/man/session), [authentication recipe](/learn/man/recipes/authentication)).
- **A data API.** An `@rpc` is a server function the browser calls directly, with typed arguments and a typed return value, and the authorization check sits at the top of the function ([rpc](/learn/man/rpc)).
- **Server code.** Route handlers and `@rpc` functions run in the same process that renders your pages ([router](/learn/man/router)).
- **File uploads.** A file input binds to a field on a form, and the files reach the server with the rest of the form, to be stored in Postgres or any object store ([file upload recipe](/learn/man/recipes/file-upload)).

## Neon, DigitalOcean or RDS

The table compares the three hosts on how they bill, how far back you can restore, what happens when a machine fails, and what else they offer, for a database with about 4 GB of memory in a US region.

| | Neon (Launch) | DigitalOcean Managed PostgreSQL | Amazon RDS for PostgreSQL |
|---|---|---|---|
| How it bills | Compute per CU-hour, storage per GB-month, no minimum ([pricing](https://neon.com/pricing)) | A fixed monthly price per node, with storage included ([pricing](https://www.digitalocean.com/pricing/managed-databases)) | Per instance-hour, plus storage ([pricing](https://aws.amazon.com/rds/postgresql/pricing/)) |
| Restoring to an earlier moment | Up to 7 days on Launch and 30 on Scale, with the history billed as storage | Any point in the previous 7 days, included ([features](https://docs.digitalocean.com/products/databases/postgresql/details/features/)) | Any point in the retention period you set ([backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)) |
| When a machine fails | No standby; Neon typically recovers from a node failure in 1 to 2 minutes ([high availability](https://neon.com/docs/introduction/high-availability)) | Optional standby nodes with automatic failover | Optional Multi-AZ standby with automatic failover |
| What else it offers | Branching, autoscaling, scale to zero | Read-only nodes, built-in connection pools | The rest of AWS in the same network |

Choose by what the database does all day. For a production app that keeps its database busy around the clock, Neon bills compute for every hour it runs, while DigitalOcean charges a fixed monthly price per node, with point-in-time recovery included and failover as a setting ([Elements vs DigitalOcean](/vs/digitalocean)), and RDS fits when the rest of your infrastructure already runs on AWS ([Elements vs AWS](/vs/aws)). Choose Neon when branching is worth having: a copy of production for every staging deploy or every review, created instantly, with compute that grows under load and stops when a branch sits idle.

Whichever you pick, the Elements app does not change. It reads `DB_HOST` and connects, and moving between hosts is a dump, a restore and a new env file. [Elements vs Supabase](/vs/supabase) compares another Postgres host with services of its own.

## Questions

### Can I use Neon as the database for an Elements app?

Yes. Set DB_HOST, DB_PORT, DB_USER and DB_PASSWORD to your Neon compute's direct connection, and set DB_DEFAULT to neondb. Elements connects over TLS and creates its app and test databases on the first build. Use Postgres 16 or newer.

### Does Elements work with Neon's connection pooler?

Use the direct connection instead, the hostname without -pooler. Neon's pooler runs PgBouncer in transaction mode, which does not support LISTEN/NOTIFY, and Elements channels and LiveTable depend on it. An Elements app is a long-running server with its own connection pool, so it does not need the pooler.

### Will my Neon database scale to zero with an Elements app?

Plan on it running all the time. An Elements app server holds a listening connection for realtime features and runs cron, and Neon's docs say long-lived connections and scheduled jobs can keep a compute active 24/7. For production, turn scale to zero off; it pays off for branches with no app attached.

### What is Neon branching good for with Elements?

A staging environment. Point staging's DB_HOST at a branch of production, and each staging deploy migrates a copy of real data before production does. Neon creates a branch instantly, without adding load to the parent, and resets it from production in one step.

### Is Neon cheaper than DigitalOcean or RDS for Postgres?

It depends on how much of the day the database is busy. For a database that runs around the clock, DigitalOcean Managed PostgreSQL and Amazon RDS list lower prices for the same memory, and DigitalOcean includes seven days of point-in-time recovery. Neon costs less for databases that sit idle, because an idle compute scales to zero.