Database Migration → home server

The alloy_lab PostgreSQL database moved from a local Docker container on the Mac to the home server. Mac, ML Desktop, and the server now share one canonical database — no divergence risk, no manual syncing, always reachable on demand.

Step by step

01Wake the server

Server was powered off — woken via Wake-on-LAN from the ML Desktop.

wakeserver   # alias for: wakeonlan 2c:56:dc:74:c4:ff
ssh r@192.168.2.42

Boot to SSH-ready: ~60 seconds.

02PostgreSQL on the server

Fresh Docker container, postgres:17 — matching the Mac's version exactly, to avoid any version-skew surprises during restore.

mkdir -p ~/docker/postgres/data

docker run -d \
  --name alloy-postgres \
  --restart unless-stopped \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=*** \
  -e POSTGRES_DB=alloy_lab \
  -v ~/docker/postgres/data:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:17

Data volume mounted at ~/docker/postgres/data — persists across container restarts and upgrades.

03Dump from the Mac

# Inside Mac's postgres container
docker exec -t postgres pg_dump \
  -U postgres -d alloy_lab \
  --no-owner --no-acl -F c \
  -f /tmp/alloy_lab_backup.dump

# Extract from container
docker cp postgres:/tmp/alloy_lab_backup.dump ~/alloy_lab_backup.dump
# Result: 71KB compressed dump

04Transfer and restore on the server

# Transfer
scp ~/alloy_lab_backup.dump r@192.168.2.42:~/

# Restore on server
docker cp ~/alloy_lab_backup.dump alloy-postgres:/tmp/
docker exec -t alloy-postgres pg_restore \
  -U postgres -d alloy_lab \
  --no-owner --no-acl -F c \
  /tmp/alloy_lab_backup.dump

All 16 tables restored, row counts matching the source exactly.

05Remote connections configured

# Allow connections from the local network (192.168.2.0/24)
docker exec alloy-postgres bash -c "
echo 'host alloy_lab postgres 192.168.2.0/24 md5' \
  >> /var/lib/postgresql/data/pg_hba.conf"

# Listen on all interfaces
docker exec alloy-postgres bash -c "
sed -i \"s/#listen_addresses = 'localhost'/listen_addresses = '*'/\" \
  /var/lib/postgresql/data/postgresql.conf"

docker restart alloy-postgres

06.env updated on the Mac

POSTGRES_HOST=192.168.2.42   # changed from localhost
POSTGRES_PORT=5432
POSTGRES_DB=alloy_lab
POSTGRES_USER=postgres
POSTGRES_PASSWORD=***
POSTGRES_SCHEMA=alloy_lab

07SSH set up on the ML Desktop

SSH server wasn't installed on the ML Desktop yet — needed for the transfer/verification steps.

sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh

ML Desktop IP confirmed: 192.168.2.210

08.env updated on the ML Desktop

Same change: POSTGRES_HOST=192.168.2.42

09Connections verified

10Live test — a new sample, written straight to the server

Added a new sample via the desktop app while connected to the server DB, to confirm the full pipeline works end to end against the new home, not just that the data survived the copy:

Connected to database: alloy_lab  ✅
Added sample: ExampleAlloy-20260903-001 (ID: 52)  ✅
3 synthesis routes auto-saved  ✅

Confirmed: calculator → screening → DB write, all working against the server.

11path_repair.py — clean

✅ All file paths in the database are valid — nothing to repair.

Raw data files remain on the Mac Desktop for now. Path repair will be needed once data physically moves to server:/mnt/storage1/datasets/alloy_lab/ — deferred to the data organization pass before Stage 3.

12Mac's old container decommissioned

docker stop postgres
docker rm postgres

Image kept temporarily as a safety net. Removable at Stage 3 start: docker rmi postgres:17

Final system architecture

┌─────────────────────────────────────────────────────┐
│  Home Server  192.168.2.42  (AMD FX-4320, always-on)│
│  ┌─────────────────────────────────────────────────┐ │
│  │  Docker: alloy-postgres (postgres:17)           │ │
│  │  Port: 5432                                     │ │
│  │  Data: ~/docker/postgres/data  (persistent)     │ │
│  │  50 samples, 16 tables, full Stage 2 schema     │ │
│  └─────────────────────────────────────────────────┘ │
│  Storage1: 2.7TB  (datasets, training runs)          │
│  Storage2: 931GB  (repos, docs)                      │
└───────────────┬─────────────────────────────────────┘
                │  192.168.2.0/24 local network
        ┌───────┴────────┐
        │                │
┌───────▼──────┐  ┌──────▼──────────────────────────┐
│  M4 Mac      │  │  ML Desktop  192.168.2.210       │
│  .env:       │  │  .env:                           │
│  host=.42 ✅ │  │  host=.42 ✅                     │
│  App + tools │  │  Ryzen 9900X + RTX 5060 Ti 16GB  │
│  Pi4/Pi5 hub │  │  Stage 3 ML training             │
└──────────────┘  └──────────────────────────────────┘

Open items (not urgent)

• ☐ Raw data migration — move the raw dataset from the Mac Desktop to server:/mnt/storage1/datasets/alloy_lab/, then run path_repair.py
• ☐ Remove the Mac's old postgres:17 image at Stage 3 start (docker rmi postgres:17)
• ☐ Replace password auth with SSH key-based auth on the server (more secure for an always-on machine)
• ☐ Confirm the ML Desktop's venv has every requirement installed and working for Stage 3 ML work

What this enables

• Single source of truth — no risk of the Mac and ML Desktop diverging
• Always accessible — the server wakes on demand via WoL, ~60s from cold
• Stage 3 ready — the ML Desktop can read training data directly from the server DB and write results back, no manual file transfers needed
• Future-proof — new machines join by updating one line in .env

A note on the journey

This migration closes a significant chapter. The alloy lab database project started as a way to replace scattered spreadsheets and manual file management with something structured, reproducible, and ML-ready. Stage 1 built the data capture layer. Stage 2 built the validated characterization pipelines — XRD, VSM, SEM — each instrument properly understood and integrated, not approximated. This migration puts the result in its permanent home.

The database now contains real, validated measurements from real samples, stored in a schema designed from the start to feed a machine learning model. That model is Stage 3 — and the infrastructure to run it is ready.

---