DataBeginner

Databases, Authentication, Authorization, and APIs

Run PostgreSQL locally, protect environment variables, and understand schemas, migrations, auth, permissions, and APIs.

4 min readReviewed Sep 5, 2026Free public access
Table of contents

A database stores application state. Authentication proves who a user is. Authorization determines what that user may do. An API defines communication boundaries between clients, servers, and other services. Design them together when an application handles user data.

1. Databases, Schemas, ORMs, and Migrations

A schema defines tables, columns, types, constraints, indexes, and relationships. An ORM helps code read and write a database through models or a query API. A migration is an ordered, reviewable schema change. A seed inserts initial or practice data.

Do not change a production database directly through a database UI without a migration and backup plan. A schema file in source code does not mean the runtime database changed. Generate, review, run, and verify migrations in the intended environment.

2. Run PostgreSQL Locally with Docker

An example Compose file for local practice:

yaml
services:
  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: local-development-only
      POSTGRES_DB: app_local
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Start and inspect the service:

bash
docker compose up -d
docker compose ps
docker compose logs db

These example credentials are only for a local computer. Never use them in production. Follow the repository's image version and configuration when they already exist.

3. Manage Environment Variables and Secrets

Use .env.local for local values and .env.example for variable names without secrets. Add secret files to .gitignore before the first commit.

dotenv
DATABASE_URL=postgresql://app:local-development-only@localhost:5432/app_local

Never place a production database URL, token, private key, or password in prompts, screenshots, logs, issues, or a client-side bundle. Treat variables readable by the browser as public.

4. Separate Authentication and Authorization

Authentication answers "who are you?" through passwords, OAuth, passkeys, or another mechanism. Authorization answers "what may you do?" through roles, ownership, permissions, tenants, and resources.

A signed-in user is not automatically allowed to read another user's invoice. Every server operation must check the session and data scope. Hiding a frontend button improves UX but does not create a security boundary.

5. Understand the API Boundary

An API receives a request, validates input, checks authorization, runs business rules, accesses the database, and returns a response. A client must not decide a final price, role, tenant ID, or approval status that belongs to server authority.

For each endpoint, document method, path, input, output, authentication, permission, errors, side effects, and idempotency. Do not expose stack traces, raw queries, credentials, or internal details in public responses.

6. Turn a Blueprint Schema into Migrations

An AI Blueprint Database Schema is a requirement and design artifact, not evidence that the runtime database is ready. Compare it with the repository ORM and migrations. Resolve naming, type mapping, constraints, indexes, foreign keys, cascade behavior, audit fields, and tenant isolation.

For risky changes, use an expand, data migration, code switch, then contract sequence. Important data needs backup and restore rehearsal. Do not remove a column only because the newest UI does not display it.

7. Test Data and Permissions

Minimum tests include:

  • valid and invalid input;
  • unauthenticated users;
  • authenticated users with permission;
  • authenticated users without permission;
  • rejected cross-user or cross-tenant access;
  • missing resources;
  • safe retries for idempotent operations;
  • transaction rollback when one step fails.

Use synthetic data. Never copy production customer records into a repository or practice environment.

8. Stop, Start, and Reset Local Services

Stop containers without deleting data:

bash
docker compose stop
docker compose start

docker compose down removes containers and networks, while named volumes usually remain. The -v option deletes volumes and their data. Do not use it until you have confirmed that data loss is acceptable.

9. Data and API Quality Gate

  • Schema and migrations agree.
  • Migrations work on an empty database and relevant upgrade path.
  • Secrets are absent from Git and client bundles.
  • Every write validates input on the server.
  • Authorization applies at the query or service boundary.
  • Tenant and ownership boundaries have negative tests.
  • Public errors are safe while internal logs remain diagnostic.
  • Backup, rollback, or recovery matches the data risk.

Official sources and references

Use these sources to confirm current commands, capabilities, prices, and limits.

Was this guide helpful?

Tell us whether the steps worked or if something needs an update.