A web application often needs persistent state that survives individual requests and server restarts. A relational database can provide that durable shared state.

Request to query to response

A typical server-side flow is

HTTP request
    ↓
validate input and authorization
    ↓
query or update database
    ↓
build HTTP response

The database is not exposed directly to the browser. Application code decides which operations a request is allowed to perform.

Parameters and untrusted input

Values supplied by users must not be inserted into SQL by string concatenation. Database drivers provide parameterized queries that keep SQL structure separate from data values.

Validation answers whether input has an acceptable form; authorization answers whether the current actor is allowed to perform the operation. Both remain necessary even when database constraints exist.

Transactions across application operations

One application action may require several related writes. A transaction can ensure that all of them commit together or none do.

For example, creating an order and its line items should not leave an incomplete order if one insert fails.

Connections

Web servers commonly reuse a limited pool of database connections rather than opening a completely new physical connection for every query.

Ownership of invariants

Application code expresses workflow and permissions, while database schemas and constraints protect persistent data invariants. Reliable systems use both layers instead of assuming either one makes the other unnecessary.