> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mov-eat.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Data model

> High-level explanation of the Moveat database model.

# Data model

Moveat uses PostgreSQL as the product source of truth.

The schema is normalized by default. Derived summaries are used only when they improve read performance or preserve historical snapshots.

## Main data areas

| Area          | Tables                                                                        |
| ------------- | ----------------------------------------------------------------------------- |
| Identity      | users, auth accounts, user channels.                                          |
| Fitness setup | user profiles, user goals, nutrition settings.                                |
| Nutrition     | meal entries, meal entry items, daily summaries.                              |
| Training      | exercises, exercise media, workout sessions, workout exercises, workout sets. |
| Progress      | weight logs.                                                                  |
| Coaching      | user coaching profile/context.                                                |

## Why profile, goals and nutrition settings are separate

They represent different business concepts:

* Profile describes the user's physical baseline.
* Goals describe desired outcome and activity assumptions.
* Nutrition settings describe calorie and macro targets.

Keeping them separate avoids accidental coupling and makes updates easier to reason about.

## Daily summaries

Daily nutrition summaries are derived rollups. They make dashboards cheaper and preserve the calorie target snapshot for a given day.

They should remain rebuildable from meal entries.

## Idempotency

Agent-originated writes should use idempotency keys. This prevents duplicated logs when external webhooks retry delivery.

## Unit system

The database stores metric canonical values. User-facing APIs can return display values based on the user's configured unit system.

## Naming conventions

Physical database names use English `snake_case`. Prisma models use singular `PascalCase` and map to physical table names.