This document describes the database architecture used by HyperFleet API.
HyperFleet API uses PostgreSQL with GORM ORM. The schema follows a simple relational model with polymorphic associations.
Primary resources for cluster management. Contains cluster metadata and JSONB spec field for provider-specific configuration.
Child resources owned by clusters, representing groups of compute nodes. Uses foreign key relationship with cascade delete.
Polymorphic status records for both clusters and node pools. Stores adapter-reported conditions in JSONB format.
Polymorphic pattern:
owner_type+owner_idallows one table to serve both clusters and node pools- Enables efficient status lookups across resource types
Key-value pairs for resource categorization and search. Uses polymorphic association to support both clusters and node pools.
clusters (1) ──→ (N) node_pools
│ │
│ │
└────────┬───────────┘
│
├──→ adapter_statuses (polymorphic)
└──→ labels (polymorphic)
Flexible schema storage for:
- spec - Provider-specific cluster/nodepool configurations
- conditions - Adapter status condition arrays
- data - Adapter metadata
Benefits:
- Support multiple cloud providers without schema changes
- Runtime validation against OpenAPI schema
- PostgreSQL JSON query capabilities
Resources use GORM's soft delete pattern with deleted_at timestamp. Soft-deleted records are excluded from queries by default.
Uses GORM AutoMigrate:
- Non-destructive (never drops columns or tables)
- Additive (creates missing tables, columns, indexes)
- Run via
./bin/hyperfleet-api migrate
# Create PostgreSQL container
make db/setup
# Run migrations
./bin/hyperfleet-api migrate
# Connect to database
make db/loginSee development.md for detailed setup instructions.
- Development Guide - Database setup and migrations
- Deployment - Database configuration and connection settings
- API Resources - Resource data models