PostgreSQL
Databasessystem_type: "postgres"Proxy PostgreSQL DSN credentials through QuantaVault and apply field-level tokenization on query parameters.
Overview#
The PostgreSQL connector seals database connection strings (DSN) in QuantaVault. The proxy engine can apply field-level tokenization on query payloads - replacing PII values with opaque tokens before they land in the database. Connection strings are decrypted only at proxy execution time inside the QuantaSeal backend.
https://api.quantaseal.io/api/v2/proxy/outboundAuth header:
X-API-Key: qs_live_...Prerequisites#
- 1A PostgreSQL 12+ database
- 2A database user with the required table permissions
- 3The full connection DSN: postgresql://user:pass@host:5432/dbname
- 4A QuantaSeal API key
Configuration#
Follow these steps to connect PostgreSQL to QuantaSeal. You can configure integrations via the Admin Console or directly via the API.
- 1
Create a dedicated PostgreSQL user: CREATE USER qs_proxy WITH PASSWORD '...'; GRANT SELECT, INSERT, UPDATE ON relevant_tables TO qs_proxy;
- 2
Seal the DSN: POST /api/v2/vault/seal with credential_type: database_dsn and values: {dsn: 'postgresql://qs_proxy:...@host:5432/mydb'}.
- 3
Create the integration: POST /api/v2/integrations with system_type: postgres.
Authentication Types#
Store the full PostgreSQL DSN as a database_dsn credential in QuantaVault. Use a dedicated least-privilege DB user scoped to only the schemas your application needs.
All credential types are sealed in QuantaVault with ML-KEM-768 + AES-256-GCM and wrapped by your tenant AWS KMS CMK before storage. See the Vault API reference for the full list of credential types and seal/unseal endpoints.
Available Operations#
QuantaSeal enforces a default-deny operation policy. Only operations listed in your integration's allowed_operations array will be permitted. Add operations when creating or updating the integration.
| Operation | Description |
|---|---|
query | Execute a parameterized SELECT query. |
execute | Execute a parameterized INSERT, UPDATE, or DELETE. |
transaction | Execute a sequence of statements in a transaction. |
tokenize_and_insert | Tokenize PII fields then insert the record. |
Code Example#
Every proxy call returns a HybridCryptoEnvelope - the response is ML-KEM-768 key-encapsulated, AES-256-GCM encrypted, and signed with ML-DSA-65 + HMAC-SHA-512. Verify both signatures before trusting the decrypted payload.
curl -X POST https://api.quantaseal.io/api/v2/proxy/outbound \
-H "X-API-Key: qs_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"integration_id": "int_01HZ9X2K4MNPQRPOSTGRES001",
"operation": "query",
"payload": {
"sql": "SELECT id, email, created_at FROM users WHERE tenant_id = $1 LIMIT $2",
"params": ["ten_01HZ9X2K4MNPQR5STUVWXYZ00", 10]
}
}'
# Response - HybridCryptoEnvelope
{
"success": true,
"encrypted": {
"ciphertext_kem": "<base64 - 1088 bytes ML-KEM-768>",
"ciphertext_data": "<base64 - AES-256-GCM encrypted query result rows>",
"nonce": "<base64 - 12 bytes>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-KEM-768"
},
"signature": {
"pqc_signature": "<base64 - ~3309 bytes ML-DSA-65>",
"hmac_signature": "<base64 - 64 bytes HMAC-SHA-512>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-DSA-65+HMAC-SHA-512"
},
"audit_event_id": "aud_01HZ9XABCDEF"
}client.encryption.decrypt(envelope). Both the ML-DSA-65 signature and the HMAC-SHA-512 signature must pass - QuantaSeal uses a bitwise & check, not short-circuit and.Troubleshooting#
password authentication failed for user
The DSN in the vault entry has an incorrect password. Rotate the vault entry: POST /api/v2/vault/rotate/{credential_id} with the new DSN.
SSL SYSCALL error - connection reset
Enable SSL in the DSN: postgresql://user:pass@host:5432/db?sslmode=require. QuantaSeal always validates server certificates.