Database Viewer

SuperBuilder includes a built-in database viewer that auto-detects your database configuration from .env files or Prisma schemas. You can browse tables, run queries, and give AI agents direct access to your data — no separate DB client needed.

Auto-Detection

When you open a project in SuperBuilder, it automatically looks for database connection details in:

• .env and .env.local files (looking for DATABASE_URL, DB_URL, POSTGRES_URL, and common variants)
• Prisma schema files (schema.prisma) — parses the datasource block
• Common ORM config files

If it finds a connection, it appears in the Database panel automatically. For most projects, there's nothing to configure — you open SuperBuilder, and your database is there.

What You Can Do

Browse schema — see all tables, their columns, types, and indexes. Understand the structure of your database at a glance without writing \d in psql.

Run queries — write and execute SQL directly in the viewer. Results display in a clean table format. Query history is saved per connection.

Inspect data — click into any table to see its rows, filter, sort, and page through data. Useful for quickly checking what's actually in the database during development.

Understand relationships — the viewer infers foreign key relationships from your schema and shows them visually, so you can understand how tables connect.

AI Agent Integration

The real power of the database viewer is that AI agents can use it too. When you give an agent a task that involves the database, it can:

• Read the schema to understand your data model
• Run queries to inspect existing data
• Verify that a migration produced the expected result
• Check that a new feature wrote data correctly

This is significantly more useful than asking an agent to reason about your database from your code alone. The agent sees the actual schema, the actual data, and can verify its assumptions directly.

Example tasks where this helps:

• "Find all users who signed up in the last 7 days but haven't completed onboarding" — the agent queries the database directly
• "Write a migration that adds a last_active_at column to the users table and backfills it from the sessions table" — the agent inspects both tables first, then writes an accurate migration
• "Debug why this query is slow" — the agent runs the query, checks the execution plan, and identifies the missing index

Supported Databases

• PostgreSQL
• MySQL / MariaDB
• SQLite
• Any database accessible via a standard connection string

Query Safety

By default, the agent runs read-only queries in the viewer. Write operations (INSERT, UPDATE, DELETE, DROP) require explicit confirmation. You can configure this:

• Read-only mode — agent can only SELECT. Safe for production database connections.
• Confirm writes — agent proposes write queries, you approve them before execution
• Full access — agent can run any query (appropriate for local development databases)

For production databases, read-only mode is strongly recommended. For local development, full access lets agents verify their own migrations without manual intervention.

Multiple Connections

You can add multiple database connections per project — for example, your local dev database and your staging database. Switch between them in the panel.

Agents can be pointed at a specific connection for a task. Common pattern: run the agent's migration work against local, then verify the output against staging before shipping.

Frequently Asked Questions

Is my database password stored?

SuperBuilder reads your .env file but doesn't store credentials separately. The connection string from your .env is used for the session and not persisted to SuperBuilder's servers.

Can I connect to a remote database?

Yes, any database reachable from your machine — remote RDS instances, cloud databases, databases behind your VPN — works the same as a local database.

Does this work with Prisma's shadow database?

Yes. If your Prisma schema defines a shadow database URL, the viewer will detect it. You can add it as a separate connection if you want to inspect it independently.

What if my project uses multiple databases?

Add each as a separate named connection. You can switch between them freely, and give agents specific instructions about which database to use for a task.

Can the agent modify my production database?

Only if you've configured the production connection with write access. For production connections, we strongly recommend read-only mode. The agent can still reason about your schema and data — it just can't modify it.