PostgreSQL integration

Last updated date:

How Seedling connects to PostgreSQL, which read-only information it uses, and how access and deletion are controlled.

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.