4. Building the Database

Alex needs a clients table for LexVault's law firm customers.

The Database section is where you design your schema and manage data. Each project gets its own isolated PostgreSQL database with full SQL access.

Creating a table

Click "New Table"

In the Database view, hit the button in the top-right corner. Enter a table name — Alex types clients.

Add columns

Use the column editor to define your schema. Supported types include text, integer, boolean, timestamp, uuid, jsonb, and more.

Set constraints

Mark columns as primary key, not-null, unique, or add default values. Foreign keys link tables together.

Or use the SQL Runner (Database → SQL tab) to create tables with raw SQL:

CREATE TABLE clients (
  id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name       text NOT NULL,
  email      text UNIQUE NOT NULL,
  firm_name  text,
  plan       text DEFAULT 'free',
  created_at timestamptz DEFAULT now()
);

Working with data

Once your table exists, you can browse, create, edit, and delete rows directly in the console:

Add rows — click "Insert Row" to open the inline editor
Edit cells — click any cell to edit it in place
Filter & sort — use the toolbar to filter by column values and sort ascending/descending
Pagination — navigate large tables with page controls
Bulk delete — select multiple rows with checkboxes and delete them at once

Migration history

Database → Migration History shows a timeline of schema changes — tables created, columns added, indexes dropped, and so on. Each entry records the action, target table/column, and timestamp.

The platform tracks DDL from any path that goes through the gateway: the console (Table Editor, SQL Runner), the SDK (eb.db.sql(), eb.schema.createTable()), and MCP tools (runSQL, createTable).

Limitation: direct database access is not audited

Migration History tracks DDL that reaches the platform via the gateway. Schema changes made through a direct database connection — for example, psql connected to your DATABASE_URL, an ORM/migration tool running on your own infrastructure, or the Scaleway database console — do not appear in the history. They are real changes against your schema and your code/queries should still work, but the audit trail won't show them.

This is a deliberate trade-off: capturing every change uniformly would require Postgres superuser privileges, which managed-Postgres providers (Scaleway, RDS, etc.) reserve for themselves. If you need a complete audit trail, prefer the gateway-mediated paths (SQL Runner / SDK / MCP) over direct DB access for any schema-changing operation.

Using the SDK

// Insert a client
const { data, error } = await eb.db
  .from('clients')
  .insert({ name: 'Acme Legal', email: 'info@acmelegal.eu', firm_name: 'Acme Legal GmbH' })

// Read all clients
const { data: clients } = await eb.db
  .from('clients')
  .select('*')

// Update a client by ID
await eb.db
  .from('clients')
  .update('some-uuid', { plan: 'pro' })

// Delete a client by ID
await eb.db
  .from('clients')
  .delete('some-uuid')

Schema management

The Schema tab gives you a visual overview of all tables, their columns, types, and relationships. Use it to add indexes, manage foreign keys, and review your data model at a glance.

Next: File Storage →