Your team already has a database. Build the app on it.

The question that stops most evaluations

"Do we have to move our data?" No. A connector points Supero at a database you already run. Once tables are bound, they behave like native Supero data — typed records, CRUD API, pagination, aggregates, SDKs, role enforcement — and your app is built on top of them the same way it would be built on anything else.

The one decision that matters is per table, not per database: does Supero keep a copy, or read yours live?

Copy it in, or read it live

• live_read works on PostgreSQL, MySQL and SQL Server. Write-through (live_readwrite) is PostgreSQL and MySQL only — a SQL Server write returns 501.
• Warehouses (Snowflake, Databricks, ClickHouse, BigQuery, Redshift, Microsoft Fabric) are always live_read — no write-back path for an analytical source.
• Oracle and MongoDB connect in sync mode.
• For database sources the decision is reversible — flipping a table keeps the same bound schema and the same app. Warehouse tables cannot be flipped; an explicit sync or live_readwrite on one is rejected.

Four steps to an app on your data

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.projects, public.clients, public.time_entries
  TO supero_reader;

{
  "name": "prod-timesheets",
  "source": {
    "plugin": "database",
    "config": {
      "db_type":  "postgresql",
      "host":     "db.internal.example.com",
      "port":     5432,
      "database": "prod",
      "schema":   "public",
      "username": "supero_reader",
      "password": "REDACTED",
      "ssl_mode": "require",
      "query_type": "table",
      "table_names": ["projects", "clients", "time_entries"]
    }
  },
  "target": {
    "tables": [
      {"source": "projects",     "schema": "project",     "mode": "live_read"},
      {"source": "clients",      "schema": "client",      "mode": "live_read"},
      {"source": "time_entries", "schema": "time_entry",  "mode": "live_read"}
    ]
  },
  "trigger": { "type": "manual" }
}

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

    PolicyDef(role="viewer", default_access="none", rules=[
        PolicyRule(entity="projects",     can_read=True),
        PolicyRule(entity="time_entries", can_read=True),
        PolicyRule(entity="clients",      can_read=True,
                   hidden_fields=["billing_contact_email", "tax_id"]),
    ]),
]

Three properties that make this safe to hand over

And on live_read, no row contents are stored on the Supero side. Each row gets a stable identity derived from the connector, stream and row key so drill-downs and references work — that identity is computed, not persisted.

What to plan for

• Live reads are as fast as your database. For PostgreSQL, MySQL and SQL Server there is no cache in front of them, so repeated reads mean repeated load on your source. Warehouse and REST sources do get a short result cache.
• Write-through is a bigger conversation than read. It is the highest-consequence place for a scoping mistake and deserves its own review, not a ride-along on a read-only one.
• Flipping a mode is not a pure flag flip. Going live needs a discovery-confirm pass so the table has its field mapping and tenant binding; going back to sync needs one sync run before the copy has data.
• File and webhook sources are sync-only. HTTP-API sources support live reads but not write-through.

Where to go from here

• Data in a warehouse rather than a database? A governed analytics portal over Snowflake and BigQuery.
• Want the full depth on live mode, including the query path? A live ops console on the PostgreSQL you already run.
• Now make it do something: Adding payments, email and SMS.