Guides / Concepts explained

What Is Postgres? The Database Behind Many Apps, Explained

Postgres (PostgreSQL) is a free, open-source relational database. What it does, why so many apps use it, key terms, and how to ask AI to design your tables.

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

Postgres (officially PostgreSQL) is a free, open-source relational database: a program that stores an app's data in tables of rows and columns, links those tables together, and answers questions about them in a language called SQL. It is known for being reliable, strict about keeping data correct, and flexible enough to handle anything from a sign-up list to a large company's records. Many web apps, and many of the services that host them, are built on it.

Why it matters when you build with AI

When an AI app builder adds "a database" to your project, there is a good chance it's Postgres. You don't have to write SQL to use it, but a little understanding goes a long way:

• You can describe data in the shape the database needs. "Customers have many orders; each order has many items" translates directly into tables.
• You can ask for the right protections. Postgres can refuse bad data on its own — a duplicate email, an order for a customer who doesn't exist — if the AI sets up the rules.
• You can read what the AI did. Table names, columns and relationships are easy to check in a table viewer, even if you never touch the code.

An everyday analogy: a very strict filing office

Imagine a filing office with a cabinet for each kind of thing — one for customers, one for orders, one for products. Every card in a drawer has the same printed boxes to fill in. Each card has a unique number, and an order card doesn't repeat the customer's details; it just says "customer #214", pointing to the customer drawer.

The clerk is strict. They won't file an order that points to a customer who doesn't exist. They won't accept a card with the date box left blank if it's required. And if you ask them to move money from one account card to another, they either do both halves or neither — never just one.

That clerk is Postgres. The drawers are tables, the printed boxes are columns, each card is a row, and the "customer #214" link is a foreign key.

What Postgres is good at

Postgres began as a research project at the University of California, Berkeley, in the 1980s and has been developed in the open by a global community since the 1990s. That long history is why it's often the default choice: it's well documented, widely supported, and every major cloud provider offers a managed version.

A worked example: turning a spreadsheet into tables

Say you run a small catering business and track everything in one spreadsheet: each row is an event, with the client's name, phone and email, the date, the menu items and the price.

Problems appear quickly. The same client appears on six rows with two different phone numbers. The menu items are typed into one cell as "canapés x40, salad x2", so you can't total how many canapés you made this month.

In Postgres, the same information becomes four tables:

Now a client's phone number lives in one place. "How many canapés did we make in March?" is a single SQL query. And when you record a new event with its items, a transaction makes sure you never end up with an event that has half its items saved.

This is the step people skip when they ask an AI to "make an app from my spreadsheet". The guide to turning a spreadsheet into an app goes further.

Key terms

• Table, row, column: a kind of thing, one instance of it, one piece of information about it.
• Primary key: the unique ID of each row, usually id.
• Foreign key: a column that points to a row in another table, like client_id.
• Schema: the design of all your tables and columns.
• Migration: a saved, repeatable change to the schema, such as "add a venue column to events".
• Query: a question or instruction written in SQL.
• Connection string: the address and password your backend uses to reach the database. It's a secret — see environment variables and secrets.
• Managed Postgres: a service that runs, backs up and updates Postgres for you.

For the everyday operations every app performs on these tables — create, read, update, delete — see what CRUD means.

Common mistakes and misconceptions

• One giant table. Copying the spreadsheet column for column leads to the same duplication problems. Split things that repeat into their own tables.
• Storing lists in one text field. "canapés x40, salad x2" in a single column can't be counted or searched properly. Use a linking table.
• No constraints. Without "email must be unique" or "every event needs a client", bad data gets in quietly and surfaces months later.
• Changing the database by hand in production. Ask for schema changes as migrations, so the change is recorded and can be repeated.
• Letting the browser talk to the database directly. The frontend should go through your backend, which checks permissions. The database password never belongs in page code.
• "Postgres is only for big companies." It runs just as happily for a 50-row waitlist, and you won't need to move off it as you grow.
• Assuming a database is a backup. It stores data; it doesn't automatically protect you from deleting it. Check what backups your host provides.

What to ask your AI builder for

• "Save [things] in a database. Tables: … with these fields: … Link each [order] to a [customer]."
• "Make email unique on customers. Make these fields required. Don't allow an order without a customer."
• "Use migrations for every schema change."
• "Add indexes for the searches we do most: orders by customer and by date."
• "All database access goes through the server. Keep the connection string in environment variables."

If you're new to the idea of a database at all, start with what a database is, then come back here. A full-stack app shows where the database sits next to the frontend and backend.

Postgres on Mythex

Mythex gives each project that needs one its own dedicated Postgres database. You don't configure it: ask in chat ("save waitlist emails to a database") or use the /database command, and Mythex attaches it, injects the connection details into your app, and can create the tables for you. A published app's database sleeps after five idle minutes and wakes on the next request, and you're charged for the time it was actually awake, from the same credit balance as building. Details are in the database docs, and dashboard templates are a good place to see data-backed apps.