How to add a database to your app

Mock data vs. a real database

When you first build an app, it is common to fake the data. You write an array of objects in your code — three sample products, a few dummy users — and render them on screen. This is called mock or hard-coded data. It is fine for designing a layout, but it has one fatal flaw: it is baked into the code and never changes. Add a product, refresh the page, and it is gone. Every visitor sees the exact same thing, and nobody's actions are saved.

A database is separate, persistent storage that lives outside your code. When a user submits a form, your app writes a row to the database. When another user visits, your app reads those rows back. The data outlives any single page load, server restart, or deployment. This is the single most important upgrade you can make to move from a demo to a product people can actually use.

SQL or NoSQL: which one do you need?

Databases come in two broad families. A SQL (relational) database — PostgreSQL, MySQL, SQLite — stores data in tables with fixed columns, like a set of connected spreadsheets. It is excellent when your data has clear structure and relationships: users have orders, orders have items, items belong to a catalogue. A NoSQL database — MongoDB, Firestore — stores flexible documents that can vary in shape, which suits fast-changing or unstructured data.

For the vast majority of business apps — stores, bookings, CRMs, dashboards, marketplaces — a relational SQL database like PostgreSQL is the right default. Your data almost always has relationships, and SQL enforces them so your data stays consistent. Reach for NoSQL only when you have a specific reason: enormous scale, genuinely schema-less documents, or real-time sync as the core feature.

Model your data before you build

Before writing any code, list the things your app deals with. Each noun usually becomes a table. For a simple store you might have users, products, and orders. For each table, decide the columns (fields) and their types, then decide how tables connect. This is called your schema, and getting it roughly right early saves a lot of rework.

• List your entities: the real-world things your app tracks (user, product, booking, invoice).
• Give each a primary key: a unique id column so every row can be referenced.
• Define relationships: an order belongs to a user (a foreign key linking order.user_id to user.id).
• Pick sensible types: text for names, integers for counts, decimal/numeric for money (never floats for rupees), timestamps for dates.
• Add timestamps: created_at and updated_at columns make debugging and sorting far easier later.

A worked example: a table booking app for a restaurant needs a bookings table with columns id, customer_name, phone, party_size, booking_time, and status. Because customers are logged in, each booking also carries a user_id that links back to the users table. That single link is what lets a customer see only their own bookings while the owner sees all of them.

Connect the database safely

A database connection needs credentials — a host, a database name, a username, and a password, often bundled into a connection string. The cardinal rule is that these secrets must never appear in your front-end code or your public repository. Anything shipped to the browser can be read by anyone. Secrets belong in environment variables on your server or hosting platform, and your database queries should run on the server side, never directly from the user's browser.

• Keep connection strings and passwords in environment variables, not in code.
• Query the database from your backend or serverless functions, not from the browser.
• Use parameterised queries so user input can never be run as SQL — this prevents SQL injection.
• Give the app database user only the permissions it needs, and take regular backups.
• Validate and sanitise every input before it touches the database.

The manual path vs. building it into the app

Traditionally, adding a database is several distinct jobs: provision a database server, write the schema and migrations, build an API layer so the front-end can read and write data, wire up the connection securely, and handle authentication so each user only sees their own rows. Each step is doable, but together they are where most non-developers stall — the app looks ready, yet the plumbing behind it takes days.

This is exactly the gap Kashvi closes. When you describe your app in plain English, Kashvi provisions a real PostgreSQL database, generates the schema from your requirements, and wires up secure server-side access and user authentication automatically. You are not clicking through mock data — a booking really saves, a product really persists, and each user genuinely sees only their own records. Because you own the full downloadable code, you can inspect the schema, run your own migrations, and take the whole thing elsewhere if you want. There is no lock-in.

Test that persistence actually works

Once your database is connected, prove it with a simple ritual: add a record, refresh the page, and confirm it is still there. Then open the app in a second browser or an incognito window and check that data created by one user behaves correctly for another. If you have authentication, log in as two different users and make sure neither can see the other's private rows. This five-minute test catches the most common mistakes — data that only lived in memory, or access rules that leak one user's data to everyone.

For Indian founders, remember that persistence underpins the features your customers expect: order history for repeat WhatsApp buyers, saved UPI or Razorpay transaction records for reconciliation, and GST-ready invoice data. None of that is possible on mock data. A real database is the foundation everything else is built on.