How does Postgres keep a booking linked to the right customer?

Give each customer a record of their own. A booking stores that customer’s record number, so the app can look up both without typing the customer details again for every reservation.

Most booking fields have a predictable shape. Postgres can also store JSON, a way to keep several named values together, for details that vary by kind of repair. Keep any field you use to enforce a booking rule easy to check.

Three rules a booking database can keep
Rule	What it does for the booking
Primary key	Gives each customer and booking a distinct identifier.
Required customer and foreign key	Require a customer number on each booking. The foreign key checks that the supplied number belongs to an existing customer.
Required, unique slot	Requires a time and keeps another booking from claiming that same slot. If several repair bays take bookings, make the bay and time unique together.

How can you check that only one reservation saves?

Work through the steps on paper first. For a running exercise, use a private practice server or a separate test service and an empty disposable database. Before you open a write session, confirm its address, database name and test login. Make sure it has no live customer records, payments or messages. Stay on paper if you cannot verify the destination.

Set up two tables and a sample customer
Create customer and booking tables with the three rules above. Add one invented customer and choose two sample times, 3:00 and 3:30.
Check that a missing customer is rejected
Try a booking for 3:00 with the customer number left unset. In a separate attempt, supply a customer number absent from the test table. Both saves should be rejected. Read the booking list separately after each attempt and check that it is still empty.
Try to reserve the same time twice
Use the invented customer for two attempts at 3:00. Save the first and let the database finish. The database should reject the second as a duplicate. If you are testing through an app, the second visitor should see that the time is taken. Read the bookings through a fresh connection and confirm the original is still the only 3:00 reservation.
Check a different time and an uncertain reply
Try 3:30 and verify it can be saved. If the reply goes missing, look up the attempted booking in a fresh read before retrying. Keep the outcome open if you still cannot confirm it.

What does the app need to connect to Postgres?

Run Postgres on a supported server or use a managed database. Give your app server a database login with the smallest set of privileges it needs. A customer signs in to your app, and the app still decides which bookings that person can read or change.

For a remote database, follow the host’s instructions for an encrypted connection that verifies the server’s identity. Keep the credentials on the app server or in an authorized service, away from code sent to visitors. All copies of the live booking app should use the same durable database.

Before choosing or upgrading a host, check the Postgres version, the database extensions your app uses and what the host supports. A database extension adds an extra capability. Try the upgrade on a separate copy you can discard.

What are you paying for when you run Postgres?

PostgreSQL’s license allows use without a database software fee. A self-managed setup still needs a server, lasting storage, updates and a recovery plan. A managed host takes on some of that work under its own terms.

Ask what your host charges for database capacity, storage and retained backups, and who can restore the database if you lose a row. A host’s sign-in add-on and file storage can have their own costs and recovery rules.

What comes back when you restore a Postgres export?

A pg_dump archive captures one database. For practice, use only the sample dump from this exercise. Before restoring, verify the address, database name and test-only login of an empty, disposable PostgreSQL deployment separate from your live server. Keep live data and services disconnected. Stay on paper if you cannot confirm the destination. After the compatibility and access checks below, restore the archive there with pg_restore and check a sample booking and its customer link. A plain SQL dump uses the psql client to load the script.

Plan separately for app settings, customer sign-in and uploaded files. Check both restored data and app access before changing where a live app connects.

What to account for before a move
What you need	How to check it
Tables, data and rules	Check the dump tool against the source database version. Set up required extensions and restore privileges at the destination. Verify rows and the rule that blocks a second 3:00 booking.
Database roles and storage locations	Roles and tablespaces are shared across a PostgreSQL installation. pg_dumpall covers those global objects, and a managed destination may require you to recreate some of them using its own controls.
Changes after an older backup	To recover to a particular time, start with a physical base backup, a copy of the data files for the whole database cluster. PostgreSQL also needs an unbroken series of archived changes called WAL from the start of that backup through the time you want to recover. Check how much of that history your setup keeps.