1. Overview
The implemented PostgreSQL connector inventories database catalog metadata through a dedicated hosted-database role. It does not ingest application table rows in the current release.
Seedling records schemas, relations, columns, routines, constraints, role membership, grants, and row-level security policy context while keeping database credentials tenant-scoped and encrypted.
2. Connection and scope
Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.
- Dedicated PostgreSQL login
- Provide the hosted instance, database, username, password, SSL mode, and root CA when required. Use a role limited to CONNECT and schema USAGE for the approved catalog population.
- Connection ownership
- This connector is workspace-only. A current Seedling workspace administrator controls installation, credential replacement, disconnect, and purge for the exact connection.
3. PostgreSQL data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Database structure
- Schemas, tables, views, materialized views, columns, types, constraints, indexes, relationships, and routines.
- Authorization context
- Roles, role memberships, database/schema/relation grants, ownership, and row-level security policies visible to the login.
- Explicit exclusion
- Application table rows and business-record values are not synchronized by the current catalog-only connector.
4. Read-only permission contract
The current connector needs catalog visibility, not application-table SELECT.
- CONNECT on the selected database — establish the exact database session.
- USAGE on approved schemas — enumerate their catalog objects.
- Catalog visibility for schemas, relations, columns, routines, constraints, roles, grants, and row-security policies.
- SELECT on application tables is not required for the current release and should not be granted solely for Seedling.
- The connector executes no INSERT, UPDATE, DELETE, DDL, role, grant, or policy mutation.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough complete object-level audience evidence for Seedling to reproduce native permissions safely. Workspace content therefore uses the connection's restricted-by-default workspace-or-no-human-access policy; administrator and steward status grant no raw-content bypass.
- Use verify-ca or verify-full plus the provider root CA when identity-verified TLS is required. Seedling supports disable and require only when the customer's approved database policy permits them.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized PostgreSQL records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored PostgreSQL credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.