A database schema is the formal description of how a database is organized: the tables it contains, the columns of each table, the data type of each column, and the keys and constraints that the data must satisfy. It is the blueprint against which every row is checked, so that the database holds structured, predictable data rather than arbitrary text.
The PostgreSQL documentation’s “Data Definition” chapter covers exactly these building blocks. It describes how tables are created with named, typed columns, and how constraints such as primary keys, foreign keys, not-null, unique, and check constraints restrict the data that a column or table may hold. Defining the schema is therefore inseparable from defining the rules the data obeys.
Schema in this sense is the design that normalization produces: the decision of how many tables to use, which columns each holds, and how they reference one another through keys. A good schema records each fact once and connects the tables so that joins can reassemble them. The constraints in the schema are what let the database, rather than every application that touches it, enforce consistency.
Because real systems evolve, schemas change over time, and the controlled, versioned alterations that move a database from one schema to the next are called schema migrations. The schema is thus both a static blueprint and a thing with a history, and tools that manage migrations exist precisely because changing the shape of live data must be done carefully.