Job board on React Router v8, Postgres (Neon) and Clerk
Type-checked against the real SDKs, migration applied to a live Postgres (Neon), connection clients load-tested, then tracked for upstream drift and re-verified when it moves. How we verify
session validation runs in server components and route handlers, not at the edge
What you're getting
React Router v8 (framework mode) — SSR, config/file routes under app/, loaders/actions, and resource routes for API endpoints.
Postgres on Neon via Drizzle ORM and the postgres-js driver.
Clerk — hosted identity (sign-in UI, sessions, user management) mounted via middleware + provider.
Job board — employer companies, job postings with employment-type and status guards, a hiring-pipeline application tracker, and per-user candidate profiles.
Setup
bun add react-router react react-dom drizzle-orm postgres @clerk/nextjsDATABASE_URLNeon pooled (-pooler) connection stringNEXT_PUBLIC_CLERK_PUBLISHABLE_KEYCLERK_SECRET_KEYCLERK_WEBHOOK_SECRETsvix secret that verifies Clerk webhook signaturesApply the schema with bunx drizzle-kit push
Initialization
Database client
Job board schema: companies, postings, applications & candidates
Companies & employersemployer tenant records owned by a Better Auth user, anchoring all postings
Job postingsindividual listings with employment-type, status, and optional salary range in cents
Applications & hiring pipelinecandidate submissions against a posting, carrying a four-stage status from applied to hired
Candidate profilesone-per-user profile row holding a headline and resume URL for applicants
Verified identity sync (Clerk)
Deploy targets
Decisions and compatibility
Framework mode (not data/library mode): routes live under app/, declared in app/routes.ts. API endpoints are resource routes (a route module exporting loader/action but no default component).
prepare: false is mandatory — Neon's pooled endpoint is PgBouncer in transaction mode, where server-side prepared statements break across the pool.
Drizzle is paired here (not Prisma): Prisma's prepared-statement reliance is incompatible with transaction-mode pooling.
Hosted: Clerk owns identity and does NOT create a local `user` table. Store `clerk_user_id` as text without a foreign key, or sync Clerk users into a local table via webhook before relying on FKs to `user`.
A unique constraint on (posting_id, applicant_id) in applications enforces one application per candidate per posting — duplicate submissions are rejected at the DB layer, not the application layer.
candidate_profiles carries a unique constraint on user_id (1:1 with Better Auth's user), so upsert logic can key on it; job_postings enforces employment_type and status values via CHECK rather than pgEnum, keeping migrations additive.
Clerk is a hosted identity provider and does not create a local `user` table. This schema's foreign keys to `user` assume a local identity table (as Better Auth provides). With Clerk, store `clerk_user_id` as a text column without a foreign key, or sync Clerk users into a local `users` table via webhook before relying on these FKs.