The app degraded progressively over a year of data growth. Four causes,
all cumulative:
1. No indexes. Apart from primary keys, unique constraints and
session.expire, no table carried an index. PostgreSQL does not index
foreign keys automatically, so every filter and join on group_id,
supplier_id, order_id and the date columns did a sequential scan.
Worst offender: user_groups.user_id, read by getUserWithGroups() on
every authenticated request.
2. N+1 in the order and delivery listings. getOrders,
getOrdersByDateRange, getDeliveries and getDeliveriesByDateRange
issued one to two queries per row to load relations. Relations are now
loaded in bulk and grouped in Node: three queries regardless of volume.
3. /api/sync-order-delivery-status reloaded the whole deliveries table on
every iteration of its loop over orders. It now uses the deliveries
getOrders() already attaches.
4. clearExpiredCache() was implemented but never called, so
invoice_verification_cache grew without bound. Now scheduled every 6h.
Also replaces the full-history downloads on the Groups and Suppliers
pages, which fetched every order and delivery with nested relations only
to count rows, with aggregate endpoints that count in the database.
Indexes are created via scripts/auto-migrate-production.sh, the script
that actually runs at deploy time, using CREATE INDEX CONCURRENTLY so no
write lock is taken. Note that server/migrations.ts explicitly ignores
the migrations/ directory and runs only hardcoded migrations; the SQL
file added there is for reference and manual application.
Verified: typecheck baseline 440 errors, 430 after, none new in the
changed code; vite build passes; server boots; functional test confirms
the aggregate endpoints match the source data including the delivered
count.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
