​
Database Overview

FindU uses Supabase as its backend platform, providing PostgreSQL databases, authentication, real-time subscriptions, and file storage. This guide explains our database architecture and why we maintain separate development and production environments.

​
Architecture Overview

FindU maintains completely separate Supabase projects for development and production to ensure data safety and enable worry-free experimentation.

​
Why Dev Database is Empty

The development database intentionally starts empty (schema only) for several critical reasons:

Data Privacy

Protecting User InformationReal user data must never leave production. This includes:
  • Personal information (names, emails, addresses)
  • Academic records (GPAs, test scores)
  • Private messages and interactions
  • Financial aid information

Development Safety

Risk-Free ExperimentationAn empty dev database allows you to:
  • Test destructive operations safely
  • Create edge-case scenarios
  • Run performance tests
  • Experiment with schema changes

Compliance

Regulatory RequirementsMany regulations require:
  • Data minimization in non-production
  • Audit trails for data access
  • Geographic data residency
  • Right to deletion compliance

Clean Testing

Predictable Test EnvironmentEmpty databases provide:
  • Consistent starting state
  • Reproducible test scenarios
  • No production data pollution
  • Faster test execution

​
Environment Comparison

AspectDevelopmentProduction
DataEmpty or test data onlyReal user data
AccessAll developersLimited team members
BackupsOptional/manualAutomated daily
RLSCan be disabled for testingAlways enforced
MigrationsTest firstDeploy after dev testing
PerformanceSmaller instanceScaled for traffic
CostFree tierPaid plan

​
Database Schema Structure

Our database is organized into several key areas:

​
Core Tables

  • students - Student profiles and preferences
  • schools - College information and statistics
  • student_school_interactions - Swipe history and matches
  • messages & conversations - Chat system

​
Partner System

  • partner_organizations - Universities, companies, nonprofits
  • partner_entities - Specific programs or departments
  • partner_users - Admissions staff accounts
  • partner_affiliations - Role assignments

​
Supporting Tables

  • scholarships - Financial aid opportunities
  • friendships - Student social connections
  • notifications - System notifications

​
Working with Environments

​
Switching Between Environments

# Switch to dev environment
./findu env switch dev

# Verify you're in dev
./findu env status
# Output: Current environment: dev
Use dev for:
  • Daily development work
  • Testing new features
  • Running migrations locally
  • Experimenting with data
Always verify your current environment before running database operations. Production mistakes can affect real users!

​
Data Flow

​
Schema Changes (Migrations)

​
Test Data Creation

  1. Local Seed Files: Create SQL files for test data
  2. Dev Database: Apply seeds after migrations
  3. Never in Production: Seeds only run in dev

​
Security Considerations

​
Access Control

  • Each environment has separate credentials
  • Service role keys are environment-specific
  • Personal access tokens for individual developers
  • RLS policies enforced in production

​
Data Isolation

  • No cross-environment queries
  • Separate connection strings
  • Different project IDs
  • Isolated storage buckets

​
Best Practices

1

Default to Development

Always work in dev unless specifically debugging production
2

Test Migrations Thoroughly

Run supabase db reset locally before pushing any migration
3

Create Realistic Test Data

Build comprehensive seed files that cover edge cases
4

Monitor Production Carefully

Use Supabase dashboard for read-only production inspection
5

Document Data Decisions

Explain why certain data exists only in production

​
Common Questions

Next, learn about creating and managing migrations or working with the schema.