Neon

When does it make sense to use Neon?

Suppose you’ve made a reading-list app and the next job is to remember which books each person finished. Neon runs a PostgreSQL database, often called Postgres, where your app can keep those records. It fits if the app already expects Postgres or you need to add that kind of database. You can keep the sign-in and upload services the app already uses.

In Postgres, a table groups records of the same kind. A reading-list table could hold a title, a reader and a finished date in each row. SQL is the language your app can use to ask for all the books a particular reader finished this month.

Which other services could you connect?

If your app already has sign-in, you can start by connecting its records. Neon also offers managed sign-in based on Better Auth and a file service called Object Storage. Check where those services are available before you build around them.

Managed Better Auth currently works in Neon’s AWS regions. It is unavailable if the project uses either of Neon’s network restrictions called IP Allow or Private Networking. Object Storage is currently available in Ohio, Northern Virginia, Frankfurt and Singapore. Check those two service pages against the location your app needs.

On a small screen, scroll the table sideways to read every column.

How do you check that the app can reach the database?

Create a test project and give it one book with a made-up title. Connect one screen and save the reader’s progress. Close the screen and open it again. The progress should come from the saved record.

In the Neon dashboard, use Connect to find the database settings for the test copy you want to use. Those settings include a database password. Give them to the part of the app that runs privately, using its protected settings. A person who opens the website should never receive the password.

If the browser needs to ask Neon for records directly, use Neon’s Data API and set its access rules. An app that asks for records through its own server can use a private connection instead.

Can two readers keep their lists separate?

Test with two ordinary accounts. One reader should be able to save, open and update their books. Try opening, changing or deleting those same entries while signed in as the other reader.

If the app uses Neon’s Data API, table permissions say what actions it may take. Row-Level Security, usually shortened to RLS, controls which individual records those actions can reach. A table permission without row filtering can expose every row that permission covers. Turning on RLS without a rule for the reader can block their own list too.

If your own server reads from the database, test that it checks who asked before returning anything private. Make the requests through the app. A database administrator sees more than a reader should.

What does the database cost when people use it?

Free is US$0. Paid database charges depend on the size of the database computer while it runs, the space your records use and how much history you keep for recovery.

An idle database can stop its computing work. Paid storage can still be billed while it sleeps. On Free, running out of monthly compute or network transfer can suspend the database until the next billing period or an upgrade. Filling the storage allowance blocks writes that add data. Check sign-in, uploads and app hosting on their own terms.

On a small screen, scroll the table sideways to read every column.

Can you recover a deleted list without losing later entries?

Check Neon’s history window, the time for which it keeps changes you can go back to. If that history reaches back before the deletion, create a separate restore branch and check what is there before deciding how to recover the list.

On Free the window is up to six hours and capped at 1 GB of history. Launch supports up to seven days and Scale up to 30 days. A paid project can be set to keep less than its plan allows, so check the setting before you rely on it.

Restoring a branch to an earlier time rewinds Postgres records and any Managed Better Auth data. Files in Neon Object Storage and deployed functions stay as they were before the restore. On a test app, open the recovered list as its owner and check its files separately. Account for books added after the deletion before you change live data.

How can you try a change away from the live database?

Start in a disposable Neon project with invented records. Make a branch there, a copy you can change independently, and use it to try adding a finished date.

A branch made from live data can carry real records, sign-in information and uploads when those services are enabled. Point your test app at the disposable branch and confirm where sign-in, uploads and messages go before opening it. Then check that you can save a finished date and still open older book records. If the change works there, decide how to apply it to the live app.

What goes with you if you move away from Neon?

Postgres export tools can copy the table definitions and records to a compatible database. Check that the new database can open the copy before changing your app’s connection.

Make a separate list of sign-in settings, files and other services. Try the replacement with a test account that already has a reading list, then check that it can also save a new book. The database import alone tells you little about whether those other pieces are ready.

Where can you learn the next steps?

• Check sign-in and private-record accessA test plan for ordinary accounts, expired sessions and attempts to access another person’s information.