A live ops console on the PostgreSQL you already run

Create a read-only database user

Do this first and the rest of the review goes quietly. Give Supero a user that can do exactly what the console needs and nothing more.

CREATE ROLE supero_reader LOGIN PASSWORD '••••••••';
GRANT CONNECT ON DATABASE prod TO supero_reader;
GRANT USAGE  ON SCHEMA public TO supero_reader;
GRANT SELECT  ON public.orders, public.order_items, public.customers TO supero_reader;
-- no INSERT, no UPDATE, no DELETE, no other tables

⏱ ~10 minutes

Connect the source

A database connector needs the reachability details and the credential. Credentials are stored as secrets and returned masked — they never enter your app bundle.

{
  "plugin": "database",
  "config": {
    "db_type":  "postgresql",
    "host":     "orders-db.internal.example.com",
    "port":     5432,
    "database": "prod",
    "schema":   "public",
    "username": "supero_reader",
    "password": "REDACTED",
    "ssl_mode": "require",
    "query_type": "table",
    "table_names": ["orders"],
    "batch_size": 1000
  }
}

Table selection is always a list under table_names; there is no singular table_name. To expose a joined, pre-narrowed slice of a messy schema, create a database VIEW and bind that — the live planner addresses a named relation. (query_type: "query", a hand-written SQL source, applies to sync mode only.)

⏱ ~10 minutes

Discover and bind

Discovery introspects the source and proposes schemas. Binding maps a source table onto a Supero schema, which is the moment the data becomes ordinary records: typed fields, references, pagination, aggregates, SDKs and the AI agent all start working.

From an AI editor over MCP the same path is six tools: build_list_data_sources → build_connect_data_source → build_discover_source → build_bind_data_source → build_run_data_source → build_list_bound_schemas.

⏱ ~20 minutes

Set each table's mode

Set orders, order_items and customers to live_read. Supero stamps a connector-level access_mode summarising the result — live-ro here — which your UI can read to decide whether to render write controls at all. When a connector mixes modes, the most permissive one wins, so check what it reports rather than assuming.

⏱ ~5 minutes

Apply roles and hide the columns that should not travel

This is the step that makes it a product rather than a database viewer. Live data honours the same policy model as native data — roles, tenant isolation and field hiding all apply.

POLICIES = [
    PolicyDef(role="tenant_admin", default_access="full", rules=[]),

    # Support: read orders and customers, never payment identifiers.
    PolicyDef(role="viewer", default_access="none", rules=[
        PolicyRule(entity="orders",      can_read=True),
        PolicyRule(entity="order_items", can_read=True),
        PolicyRule(entity="customers",   can_read=True,
                   hidden_fields=["payment_token", "card_last4", "tax_id"]),
    ]),
]

Then verify it the only way that counts: sign in as viewer and try to sort or filter by card_last4. A refusal is the correct answer — the query never reaches your database. Hidden columns are also stripped from responses, but the refusal is the part that matters: a filter on a hidden column would otherwise leak its value through the result count.

⏱ ~30 minutes

Build the console on top

From here it is an ordinary Supero app. Generate the screens from the bound schemas, or hand-build the UI against the same CRUD API. Aggregates, group-by counts and distinct-value lookups run on your source, so a status breakdown across a very large table is a query your database is already good at.

The in-app AI agent comes along for free: it derives search_/get_ tools per bound entity plus shared analytics tools (db_stats, db_count_by, db_distinct, db_aggregate), all going through the same access engine. "How many held orders per region this week?" is answered by your database, under the asker's own permissions.

⏱ ~45 minutes