Job board, built on every verified stack.
Job board: employer companies, job postings with employment-type and status guards, a hiring-pipeline application tracker, and per-user candidate profiles.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Job board gives you
Hiring is two-sided, and this schema splits along that seam. companies and job_postings belong to the employer; candidate_profiles belongs to the applicant; applications is the only table that touches both. Each side keys into Better Auth's user.id as text — an employer is a user who owns a company row, a candidate is a user who owns a profile row — and nothing stops one person from being both, because neither side declares a role column. companies is the employer container: owner_id, a name, an optional website, and idx_company_owner so a signed-in recruiter reaches their company ids in one lookup. Postings cascade from it.
job_postings stores compensation as two nullable bigint columns, salary_min_cents and salary_max_cents — integer cents so no float touches money, and bigint rather than integer so a large annual figure in a weak currency cannot overflow the range. employment_type (full_time, part_time, contract) and status (open, closed) are text under the named CHECKs job_postings_type_check and job_postings_status_check, which keeps adding an internship type a constraint change rather than an ALTER TYPE. Its single index, idx_posting_company_status on (company_id, status), is built for the employer's own list of roles. applications is the pipeline.
status walks applied, screening, rejected, hired under applications_status_check, and the composite unique applications_posting_applicant_unique on (posting_id, applicant_id) makes one application per candidate per posting a database fact rather than a guard in a route handler — a resubmit fails outright, or becomes a no-op under ON CONFLICT. idx_application_posting serves the recruiter's read: everyone who applied to this role, one row each. candidate_profiles is strictly one-to-one with identity, since user_id is NOT NULL and UNIQUE against user.id, which makes it an upsert target instead of a list. The asymmetry is worth seeing before you build screens: every index here runs from an employer toward candidates. There is no index on applications.applicant_id, and the composite unique leads with posting_id, so a candidate's 'roles I applied to' page scans.
Nor is the public board covered — browsing open postings across companies cannot use (company_id, status). Both are one CREATE INDEX away, and neither ships in the migration.
Built for
job_postings through idx_posting_company_status on (company_id, status); companies.idx_company_owner on owner_id gets from the signed-in user to their company ids first, so neither hop scans.
applications, via idx_application_posting on posting_id. Because applications_posting_applicant_unique guarantees one row per candidate per posting, the row count is the applicant count — no DISTINCT needed.
the composite unique applications_posting_applicant_unique on (posting_id, applicant_id) turns a second apply into a constraint violation at write time, so the submit endpoint can be idempotent instead of read-then-insert.
applications grouped by status — the four values applied, screening, rejected and hired are pinned by applications_status_check — inside the posting_id range that idx_application_posting already scopes.
candidate_profiles, whose user_id column is NOT NULL and UNIQUE against Better Auth's user.id; that unique index makes the fetch a single key lookup and the write a safe upsert.
Why Job board, specifically
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.