Skip to main content
Pro plan required. The Schema Viewer lets you see the structure of every table in your database. Instead of guessing what columns exist or what types they use, you can inspect the full schema right inside Nativeline.

​
What You Can See

The Schema Viewer surfaces all the structural details of your database:

​
Columns and Data Types

Every column is listed with its PostgreSQL data type. Common types you’ll encounter:
TypeUsed For
textStrings — names, descriptions, content
integer / bigintWhole numbers — counts, quantities
booleanTrue/false flags
uuidUnique identifiers — primary keys, references
timestamp / timestamptzDates and times — created_at, updated_at
jsonbStructured JSON data — metadata, settings
float / numericDecimal numbers — prices, coordinates
text[] / integer[]Arrays of values — tags, categories

​
Keys and Constraints

  • Primary keys — The unique identifier for each row, typically id
  • Foreign keys — References to rows in other tables, defining relationships
  • Unique constraints — Columns that must have distinct values across all rows
  • Not-null constraints — Columns that cannot be empty
  • Check constraints — Rules that validate column values (e.g., price must be positive)

​
Default Values

See which columns have default values set. Common defaults include:
DefaultUsed On
now()Timestamp columns like created_at
gen_random_uuid()UUID primary keys
true / falseBoolean flags
'draft'Status columns with an initial state
0Numeric counters

​
Indexes

View the indexes on each table. Indexes speed up queries on frequently searched columns. The Schema Viewer shows which columns are indexed so you can understand your database’s performance characteristics. Common indexes you’ll see:
  • Primary key index — Created automatically on every primary key
  • Foreign key indexes — Often added to speed up JOIN queries
  • Unique indexes — Enforce uniqueness and speed up lookups (e.g., on email)
  • Custom indexes — Added for columns you query frequently

​
Row Level Security (RLS) Policies

Supabase uses RLS to control who can read and write data. The Schema Viewer shows you:
  • Whether RLS is enabled on a table
  • What policies are defined
  • What operations each policy allows (SELECT, INSERT, UPDATE, DELETE)
  • The conditions for each policy
Understanding RLS is important because it affects what data your app’s users can access. If your app isn’t showing data it should, an overly restrictive RLS policy is often the cause.

​
Relationships Between Tables

See how your tables connect to each other through foreign keys. This is critical for understanding your data model — which table references which, and how records relate across tables. For example, if posts.author_id references users.id, the Schema Viewer shows that relationship so you can understand the connection between posts and users.

​
Why It Matters

The Schema Viewer isn’t just informational. It directly helps you build better apps:

​
Verify the AI’s Work

When you ask the AI to create a table or add columns, open the Schema Viewer to confirm it did exactly what you expected. Check that column types are correct, foreign keys point to the right tables, and RLS policies are in place.

​
Plan New Features

Before asking the AI to add a new feature that touches the database, review the existing schema. Understanding what tables and columns already exist helps you write better prompts and avoid duplicate structures.

​
Debug Data Issues

When something isn’t working right, the schema often holds the answer. A column might be the wrong type, a foreign key might be missing, or RLS might be blocking access.
When asking the AI to add features that touch the database, reference the schema: “Add a comments table that references the posts table via post_id.” The more specific you are about relationships, the better the result.

​
Example Workflow

Here’s how the Schema Viewer fits into a typical build session:
  1. You ask the AI: “Create a posts table with title, body, and author”
  2. The AI generates a migration and applies it
  3. You open the Schema Viewer to verify the table structure
  4. You notice the AI used text for author instead of a foreign key to users
  5. You ask the AI: “Change author to a uuid foreign key referencing users.id”
  6. You verify the updated schema in the Schema Viewer
This feedback loop — prompt, verify, refine — is how you build a solid database.

​
Reading the Schema Effectively

When you open the Schema Viewer for a table, here’s a systematic way to read it:
  1. Start with the primary key — Usually id with type uuid. This confirms the table’s identity column.
  2. Look at foreign keys — These tell you how the table relates to others. A user_id uuid REFERENCES users(id) column means each row belongs to a user.
  3. Check data types — Make sure they match your expectations. A price column should be numeric, not text.
  4. Review nullability — Columns marked NOT NULL are required. Nullable columns are optional. This affects how your app handles forms and validation.
  5. Check RLS — If RLS is enabled, review the policies to understand access control.

​
Schema Viewer vs. Data Browser

These two tools are complementary:
Schema ViewerData Browser
Shows table structureShows table data
Column names and typesActual row values
Relationships and constraintsLive records
Answers “what does this table look like?”Answers “what’s in this table?”
Use the Schema Viewer to understand your database’s design. Use the Data Browser to see what’s actually stored.
The Schema Viewer reflects the current state of your database. If you apply a migration that adds a column, the Schema Viewer shows it immediately.

Database Overview

Learn about all the database management tools available in Nativeline.

Data Browser

View the actual data stored in your tables.