How to Add a Database to an App You Vibe-Coded

You described an app, an AI agent built it, and it worked — right up until you refreshed the page and everything you typed disappeared. Or a friend tried your app and couldn't see the data you'd added. That's the moment almost every vibe-coded project hits: it was never actually storing anything, it was just holding state in memory or in the browser, and now it needs a real place to keep data. This post walks through how to recognize that moment, what your options are, how to explain the need to an agent without writing a line of SQL yourself, and what tends to go wrong the first time.

How to tell you actually need a database

Not every project needs one. A single calculator page or a static portfolio site doesn't. You know you've crossed the line when any of these is true:

• Data needs to survive a refresh. If closing the tab and reopening it should show the same to-do list, notes, or settings, you need something that outlives the browser session.
• Data needs to be shared across users or devices. If one person adds an item and another person (or you, on your phone) should see it too, local browser storage can't do that — it's stuck on one device in one browser.
• You need to query, filter, or sort data later. Once you're asking things like "show me all orders from this week" or "find users who signed up in July," you need something structured enough to search, not a flat file you re-read every time.
• More than one type of data is connected. Users have posts, posts have comments, comments have likes — once you have relationships like that, you're describing a database whether you meant to or not.

If none of that applies yet — say, it's a single-player tool that only needs to remember your last input — you can often get away with the browser's own local storage for a while longer. But the moment "share this with someone else" or "come back to it tomorrow" enters the picture, it's time.

The beginner-friendly options, ranked by how much you need to think about

You don't need to become a database administrator to add one. In order of simplicity:

1. A JSON file, for genuinely tiny projects. If it's just you, on one machine, with a small amount of data (a personal log, a scratch list), a plain JSON or SQLite file that your app reads and writes to disk can work fine. It's the lowest-effort option and it's honestly fine for prototypes — just know it doesn't scale past one user or one machine gracefully.
2. A backend-as-a-service (BaaS), like Supabase or Firebase-style platforms. This is the sweet spot for most vibe-coded apps that need to go live. You get a hosted database, a way to log users in, and often a simple API — all without running your own server. You describe your data, click a few buttons (or have your agent do it), and you have a real multi-user backend.
3. A hosted Postgres or MySQL instance. More control, more standard, and what most production apps eventually run on. Slightly more setup than a BaaS, but still just a matter of creating a database instance through a provider's dashboard and connecting your app to it with a connection string.

For a first real database, a BaaS option is usually the least friction: it bundles the database with the parts you'd otherwise have to wire up yourself, like authentication and access rules.

How to describe what you need to an agent, in plain language

You don't need to know SQL to get this right — you need to be specific about your data, the same way you'd describe it to a person. Instead of trying to write CREATE TABLE, describe:

• What "things" your app tracks. "I have tasks, and each task has a title, a due date, whether it's done, and who created it."
• How those things relate to each other. "Each task belongs to one user. A user can have many tasks."
• What needs to be unique or required. "Every user needs a unique email. A task always needs a title, but the due date is optional."
• What you'll want to look up later. "I'll want to find all tasks that aren't done yet, and all tasks due this week."

That's enough for a competent agent to design the actual tables, columns, and types, and to write the queries for you. The plain-language version is also easier for you to sanity-check — if the agent says "so tasks and users, one-to-many, got it," you can catch a mistake before any code gets written, which is much easier than debugging a wrong schema after the fact.

Common pitfalls when a vibe-coded app gets its first database

A few things trip up almost everyone the first time real persistence gets added:

• Secrets end up in the wrong place. Your database connection string or API key is a secret — it should live in an environment variable, not hardcoded in a file that gets committed to git. If you paste a database URL directly into your source code "just to get it working," it's very easy to forget to remove it before sharing or publishing the project. Ask your agent to use environment variables from the start, and double-check nothing sensitive is sitting in a file you're about to commit.
• Duplicate data isn't tested. What happens if two people sign up with the same email, or you submit the same form twice by accident? If nothing enforces uniqueness, you'll quietly end up with duplicate rows and confusing bugs later. Ask explicitly: "what happens if this data already exists?"
• Missing data isn't tested. What if a required field is left blank, or an optional field is genuinely absent? Apps that only get tested with perfectly filled-in data tend to break the first time a real user leaves something out.
• No plan for what happens when the database is unreachable. Even hosted databases have occasional hiccups. An app that just shows a blank white screen when the connection fails is a worse experience than one that shows "something went wrong, try again."
• Local testing data leaking into production, or vice versa. Once you have a real database, it's worth keeping a separate one for testing so you're not experimenting on real user data — or accidentally wiping it.

None of these are exotic problems. They're the standard set of things that any backend has to handle, and asking your agent directly — "what happens if this already exists?" or "where should the database URL be stored?" — is usually enough to get it handled correctly the first time.

Putting it together

Adding a database isn't really a coding skill you need to learn — it's a description skill. Know when you've actually crossed the line into needing one (refresh-proof, shareable, queryable data), pick the option that matches your project's size (JSON file for a solo prototype, a BaaS for anything with real users, hosted Postgres once you're past the basics), describe your data in plain language the way you'd explain it to a coworker, and ask directly about the edge cases — duplicates, missing fields, and where secrets live — before you consider it done.

meshcode is a native desktop app for exactly this kind of back-and-forth: you can describe the schema in plain language, have the agent wire up the database and the environment variables, and keep iterating without leaving the app. It's free to start, with pay-as-you-go pricing (top up from $1, no subscription) once you go past the free usage.

👉 Download meshcode — Mac, Windows