A performance-focused e-commerce template based on NextFaster, adapted to run on a local PostgreSQL database with no ORM (direct SQL via pg).
This fork is intentionally set up for speed + observability: you can see what queries run, control caching behavior, and avoid accidental DB overload from aggressive prefetching.
- ✅ Local Postgres (no hosted DB required)
- ✅ No ORM (for now) — direct SQL queries
- ✅ Prefetch disabled on heavy routes to prevent DB query explosions
- ✅ Uses Next.js server caching (
unstable_cache) - ✅ AI features removed/disabled
- Next.js (App Router)
- PostgreSQL (local)
- node-postgres (
pg) - next/image
pnpm installcreatedb nextfasterPGHOST=localhost
PGPORT=5432
PGDATABASE=nextfaster
PGUSER=postgres
PGPASSWORD=your_password
# Optional tuning
PGPOOL_MAX=10
PG_IDLE_TIMEOUT_MS=30000
PG_CONN_TIMEOUT_MS=5000pnpm devNext.js can prefetch RSC payloads for <Link /> targets. In data-heavy pages, this can trigger many DB queries (especially when lots of links enter the viewport).
This fork disables prefetch where it caused DB overload. You can selectively re-enable it later for “cheap” routes once caching is strong enough.
Read-heavy queries are wrapped in unstable_cache so repeat navigations are fast.
If you add mutations later, consider switching to tag-based invalidation for instant freshness.
Uses a pg.Pool. In Next.js dev (HMR/Turbopack), prefer a singleton pool pattern so you don’t accidentally create multiple pools during reloads.
For common pagination/listing patterns like:
WHERE subcategory_slug = $1
ORDER BY slug
LIMIT 20
WHERE subcategory_slug = $1
AND slug > $2
ORDER BY slug
LIMIT 20;A helpful index is:
CREATE INDEX IF NOT EXISTS products_subcategory_slug_slug_idx
ON products (subcategory_slug, slug);- DevTools → Network: look for repeated
?_rsc=fetches (RSC payloads / prefetch) - Time DB calls around
pool.query(...) - Monitor pool usage:
pool.totalCountpool.idleCountpool.waitingCount
- Use
EXPLAIN (ANALYZE, BUFFERS)on slow queries
Based on NextFaster by: