Guides / Prompting and shipping

How to Add a Database to Your App (Without Losing Data Later)

How to add a database to an app you built: when you need one, Postgres vs hosted options, designing tables, prompts to use, and mistakes that lose data.

Mythex Team · 2026-09-29 · 6 min read

To add a database to your app, pick a managed relational database (Postgres is the usual default), keep its connection string in a server-side secret, create one table per kind of thing your app stores, and make your backend — never the browser — read and write to it. If you build with an AI app builder, you can usually just say "save this to a database" and the agent sets up the tables and code; your job is to describe the data clearly and check it actually persists.

This guide covers when you need a database, the main options, how to describe your data, and the mistakes that cause lost or leaked data.

When your app needs a database

You need a database when your app has to remember something after the page is closed, or share data between people. Typical signs:

• Visitors submit something: a form, a sign-up, a booking, an order
• Users have accounts with their own saved content
• An admin needs to see or edit what others created
• You want reports or counts over time

You don't need one for a static site where everyone sees the same content, like a portfolio or a simple landing page. If you're unsure what a database actually is, read what is a database first.

Your options

For most small and medium web apps, a relational database like Postgres is the right default. It is good at relationships (a customer has many orders), keeps data consistent, and lets you answer questions later with SQL. See what is Postgres for a plain-English overview.

Describe your data before you build

The most useful thing you can do is write down the things your app stores and how they connect. You don't need database jargon. For a booking app:

• Customers: name, email, phone
• Services: name, duration, price
• Bookings: which customer, which service, start time, status (pending, confirmed, cancelled)

That's three tables. "Which customer" and "which service" become links (foreign keys) between them. Getting this right early matters far more than any technology choice, because changing the shape of data that already has real rows in it is harder than changing a page layout.

A few rules of thumb:

• One table per kind of thing. Don't pack orders into a text column on the customer.
• Give every row an ID and a created-at time. You'll want both later.
• Use proper types. Dates as dates, money as whole cents or a decimal type, not as text.
• Mark required fields as required. Let the database reject bad data, not just the form.

Example prompts

Start with one feature at a time rather than dumping a whole schema:

Add a database to this app. Create a bookings table with customer name, email, service, start time and status (pending, confirmed, cancelled; default pending). Save submissions from the booking form to it, show a success message, and add an admin page that lists bookings newest first.

Then extend it:

Add a services table (name, duration in minutes, price in cents). Replace the free-text service field on bookings with a link to services, and migrate existing bookings without deleting them.

And tighten it:

Make sure all database reads and writes happen on the server. The browser must never receive the database connection string. Validate the email and start time on the server before inserting.

Step by step

1. List your data as above: things, fields, links between them.
2. Create the database. In an AI builder, ask for it in chat. Elsewhere, create a managed Postgres instance and copy its connection string.
3. Store the connection string as a secret (an environment variable on the server), never in code. See environment variables and secrets.
4. Create the tables. Use migrations — versioned scripts that change the schema — so changes are repeatable and reversible.
5. Build the server routes that create, read, update and delete rows (CRUD). The browser calls these routes; it never talks to the database directly.
6. Wire the UI to those routes: forms that save, lists that load, empty states when there's nothing yet.
7. Test persistence. Submit something, reload the page, open it in a different browser. If the data isn't there, it wasn't saved to the database.
8. Check access. Log in as a second user and confirm you can't see or edit the first user's data.
9. Publish, then test again on the live URL, since the published app may use a different connection than your preview.

Common mistakes

• Saving to the browser and thinking it's saved. localStorage looks like it works until someone opens the app on another device. Always test in a second browser.
• Putting the connection string in frontend code. Anyone can read frontend code. That gives them your whole database.
• No access checks. "Show my orders" must filter by the logged-in user on the server, not in the UI. This is the most common security hole in AI-built apps; our security checklist covers it.
• Destructive schema changes. Asking to "rename the table" or "change the structure" can drop and recreate it. When real data exists, say "migrate the existing rows, don't delete anything".
• Storing files in the database. Images and PDFs belong in file storage, with only their URL or key in a table. See how to add file uploads.
• No backups. Know how your platform backs up data and how you'd restore it before you have customers.

Checklist

• Every kind of thing has its own table with an ID and created-at time
• Required fields and types are enforced by the database
• The connection string lives only in server-side secrets
• All reads and writes go through server routes
• Each user can only read and change their own rows
• Data survives a reload and shows up in a different browser
• Schema changes use migrations and keep existing rows
• You know how backups and restores work
• The live app has been tested after publishing

Adding a database in Mythex

On Mythex, each project can get its own dedicated Postgres database, on both Free and Pro. You usually don't click a separate "attach" button: ask in chat ("save waitlist emails to a database") or type /database, and the connection details are injected into the workspace and your published app. Project settings shows whether a database is active.

The database sleeps after 5 idle minutes and wakes on the next request. Published usage is charged for the time it was actually awake, from the same credit balance you use for building. If you add a database after you've already published, publish again so the live app picks it up.

See Database and the Build a CRUD app recipe in the docs. For the login side of per-user data, read how to add login to your app.