dbportal 0.3.0

Virtual datasources, on top of 0.2.3.

Virtual datasources (first step)

• type: virtual with members: [a, b] in the seed file or the admin API: two to eight PostgreSQL or MySQL datasources of the same environment opened as one. In the studio each member is a catalog named by its id, so a statement joins orders.public.pedidos with crm.crm.clientes; the explorer lists the members with their schemas and tables.
• Who may open it is whoever may open every member, on top of its own roles. It writes for nobody, exports only where every member's rule allows, and each member is resolved with the credentials the person resolves for it (Vault, ${ENV}, the read-only pool).
• The session is an embedded DuckDB one, opened per person with a memory ceiling, the members attached read-only, then locked: measured to refuse every attach, load, file read, setting change and write. A statement is refused before the engine when it is not a read or reaches for postgres_query and its kin.
• The session runs in a child process the server spawns (runner.mjs), credentials on stdin only: a fault in the engine's native code ends one session, never the server, and the next request opens a new one. The image bakes the postgres and mysql extensions in (DUCKDB_EXTENSION_DIR) and ships the runner (DBPORTAL_VIRTUAL_RUNNER).
• Measured before it was built: a million rows in PostgreSQL joined with two hundred thousand in MySQL in 170 ms, filters pushed down to both engines. Verified on two real PostgreSQL databases in CI.
• Not yet: the admin sheet's members editor (declare in the seed file or through the API for now), masking by member, an audit line per member, export/runbooks/alerts on a virtual datasource. docs/providers/virtual.md, docs/SEED_CONNECTIONS.md "Virtual datasources", docs/CONTEXT.md §4.44.

Operations

• Image ghcr.io/klinux/dbportal:0.3.0, signed keyless with SBOM and provenance. Helm chart charts/dbportal 0.1.6 (appVersion 0.3.0). No configuration changed for an install without virtual datasources.