Database

Every project has its own dedicated Postgres database in the region you chose. You can shape and browse it in the console, read and write it from your app through the SDKs, script it with the sov CLI, and connect any Postgres tool to it directly.

#Create and edit tables in the console

Open Table Editor. The left column lists the tables of the selected schema (public by default); pick one to browse its rows. Use Filter rows and Sort to narrow them down, Insert to add a row, and click a cell to edit it.

New table

New table opens a panel where you set the name, an optional description, the columns and who may access the rows:

• Columns — name, type, default value, primary key, nullable and unique. Types include numbers (int2/int4/int8, numeric, float4/float8, serials), text (text, varchar), dates and times (date, timestamptz, interval, …), bool, uuid, json/jsonb, bytea, network and geometric types.
• Foreign keys — link a column to another table's column.
• Row access — presets that create access policies for this table (below). Without one, app users can't use the table.

#SQL Editor

• Run with ⌘/Ctrl + Enter. Runs the whole script, or only the selected text. All statements of a script run in one transaction: if one fails, nothing is kept.
• Mode: Run executes; Explain shows the query plan without running it; Dry run runs the script and rolls it back, so you can check a change safely.
• Auto LIMIT adds LIMIT 100 (configurable) to queries without one, so a big table can't flood your browser.
• Save keeps a query privately or shares it with your team; Format tidies the SQL.
• Schema changes made here (create, alter, drop) are recorded as Migrations automatically.
• Owners and admins can change the schema; other roles can run queries but not schema changes.

#Query from your app

data.sql() sends one statement with its values. Placeholders $1, $2, … are bound by the database: a value can never become part of the SQL, which is what protects you from SQL injection. Never build SQL by concatenating user input.

// Read
const { columns, rows } = await sovaria.data.sql(
  'select id, name, price_cents from products where price_cents <= $1 order by name limit $2',
  [5000, 20],
)
// rows: [[42, 'Notebook', 1299], ...] in the order of `columns`
const products = rows.map((r) => Object.fromEntries(columns.map((c, i) => [c, r[i]])))

// Write — "returning" gives you the new row back
const { rows: [[id]] } = await sovaria.data.sql(
  'insert into products (name, price_cents) values ($1, $2) returning id',
  ['Notebook', 1299],
)

Response

{
  "columns": ["id", "name", "price_cents"],
  "rows": [[42, "Notebook", 1299]],
  "row_count": 1,
  "txid": 0
}

What apps can run

• SELECT, INSERT, UPDATE, DELETE, EXPLAIN and read-only WITH queries — one statement per request.
• Schema changes (create, alter, drop) are not allowed from app code: make them in the console, with migrations or the CLI.
• Writes can't be hidden inside WITH, EXPLAIN ANALYZE is refused (it would execute the statement), and app users can't read system catalogs.
• Up to 100 parameters and 64 KB of SQL per request. Values may be strings, numbers, booleans, null, or JSON objects/arrays (sent as jsonb). When Postgres can't infer a type (e.g. select $1), add a cast: $1::int.

#Who can read and write which rows

App users and the anon key have no access to a table until you allow it. Two layers decide:

1. Access policies (Policies page, or a Row access preset) decide whether a caller may run SELECT/INSERT/UPDATE/DELETE on the table at all.
2. Row-level security in Postgres decides which rows: with RLS enabled and forced on a table, your create policy rules filter every query, and Sovaria lets them decide when no access policy does.

Console members (in the SQL editor and Table Editor) and the service role key are not limited. Details and patterns: Row-level security and access.

#Schema, relationships and indexes

• Add indexes for columns you filter or join on, and for columns used in row-level security policies.
• Webhooks call a URL when rows are inserted, updated or deleted.
• Extensions lists the Postgres extensions you can enable (for example pgcrypto, pg_trgm).

#Connect directly with Postgres tools

#Database from the CLI

sov db tables                                   # tables in the linked project
sov db sql "select count(*) from orders"         # run SQL
sov db create-table reviews '[{"name":"id","type":"SERIAL","primary_key":true},{"name":"body","type":"TEXT"}]'
sov db pull                                      # write the current schema as a migration snapshot
sov db diff                                      # compare the live schema with that snapshot
sov db seed                                      # run your seed SQL
sov db migrations new add_reviews                # new timestamped migration file
sov db migrations push                           # apply pending migrations

Every command and option: CLI reference.

#React to changes

Turn on Realtime → Database change data capture for a table to push its inserts, updates and deletes to subscribed clients — they only receive rows they may read. See Realtime.

#Errors