FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Windows psql Workflow
Connect from Windows with psql Use the native PostgreSQL client to prove connectivity before adding an ORM
When a raw PostgreSQL client works, we have isolated the database connection from framework complexity.
PowerShell → psql → Supabase endpoint →
This is a direct database-client test; Next.js, NestJS and Prisma are not involved.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Windows psql Workflow
Why psql matters psql is PostgreSQL's command-line client. It lets us prove that host, port, role, password and SSL settings work before introducing Prisma.
Verify the client In ordinary PowerShell:
psql --version
If Windows cannot find it, Phase 07's PostgreSQL tooling setup or PATH must be corrected before proceeding.
Recommended connection style Copy the exact Session pooler values from Supabase. For a secure interactive connection, a parameter- style command avoids some URI encoding confusion:
psql "sslmode=require host=<POOLER-HOST> port=5432 dbname=postgres user=postgres.<PROJECT- REF>"
psql will prompt for the password if it is not supplied through another secure mechanism.
WHY PROMPT FOR THE PASSWORD?
It keeps the password out of the command line and reduces the chance that it is captured in shell history, screenshots or process inspection.
Stronger certificate verification Supabase documents verify-full using the project's downloaded root certificate:
psql "sslmode=verify-full sslrootcert=C:\path\to\prod-supabase.cer host=<POOLER-HOST> port=5432 dbname=postgres user=postgres.<PROJECT-REF>"
First interactive commands select current_database(), current_user; select version(); select now(); \conninfo \dt \q
Volume 03 - Database Engineering Book 5 of Phase 08
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Windows psql Workflow
\conninfo Shows information about the current connection.
\dt Lists visible tables.
\d table_name Describes a table.
\q Exits psql.
Run a SQL file from PowerShell psql "<connection options>" -v ON_ERROR_STOP=1 -f ". \reference\SQL_Lab\00_practice_schema.sql"
ON_ERROR_STOP=1 is valuable for scripts: psql exits with an error status instead of continuing silently after a SQL failure.
Connection checkpoint
[ ] psql --version works.
[ ] SSL connection succeeds.
[ ] current_database() returns postgres or your selected database.
[ ] current_user matches the role expected for your connection method.
[ ] \conninfo confirms the target.Official references used for this phase (verified 2026-09-17): Supabase Database Overview - https://supabase.com/docs/guides/database/overview Connect to your database - https://supabase.com/docs/guides/database/connecting-to-postgres Connecting with psql - https://supabase.com/docs/guides/database/psql Tables and data - https://supabase.com/docs/guides/database/tables Securing your data - https://supabase.com/docs/guides/database/secure-data PostgreSQL 18 psql - https://www.postgresql.org/docs/18/app-psql.html
Volume 03 - Database Engineering Book 5 of Phase 08
CI turns repository rules into automated gates. A useful pipeline must be understandable, reproducible locally, secure, and able to fail for the right reasons.
Restate the goal of “Windows psql Workflow” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: git event → runner → install → quality gates → artifact/deploy decision. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A Supabase project configured for TaskFlow development with documented connection paths and safe environment variables.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
name: CI
on: [pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: corepack enable
- run: pnpm install --frozen-lockfile
- run: pnpm lint && pnpm typecheck && pnpm test && pnpm buildDo not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Compare Node/pnpm versions, lockfile state, environment variables, OS assumptions, and generated artifacts.
Set least-privilege permissions at workflow/job level and isolate untrusted pull-request code from secrets.
Without copying the final source, create a second small scenario that applies “Windows psql Workflow” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Test connectivity from the API environment and diagnose a deliberately incorrect host/port/password.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Committing database credentials
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.