Database
PostgreSQL is the authoritative store for DALP application data, with validated connection settings, TLS modes, pooling, UTC sessions, health checks, and operator-owned HA and backup planning.
Overview
DALP uses PostgreSQL as the application data store for identity records, asset configuration, indexed chain state, workflow checkpoints, and audit records. Platform services connect through a validated database loader that creates PostgreSQL pools, applies TLS settings, sets UTC sessions, and exposes a health check for operational monitoring.
The deployment operator chooses the hosting topology, backup retention policy, and managed cloud service level. Those choices must match the selected self-hosting pattern, compliance policy, and tested recovery plan.
Data domains
| Domain | Content | Operational concern |
|---|---|---|
| Identity | Users, roles, sessions | Access control, account recovery, audit evidence |
| Configuration | Asset definitions, system settings | Change control and low-tolerance configuration |
| Indexed state | Blockchain-derived data | High-volume, append-oriented chain observations |
| Workflow | Execution engine state | Checkpointed execution and resumable transactions |
| Audit | Activity logs, compliance records | Retention, review, export, and SIEM routing |
Connection model
DALP services use a PostgreSQL connection pool rather than opening one connection per request. The pool configuration accepts minimum and maximum connection counts plus idle and connection timeouts in seconds. The loader validates that the minimum pool size does not exceed the maximum and defaults to a small pool when no override is provided.
The connection can be supplied as a PostgreSQL URL or as host, port, database, username, and password fields. If a URL is used, DALP rejects a URL-level options query parameter because it can override the pool-level session options that set timezone and schema search path.
Every pool connection carries an application_name. PostgreSQL exposes that value in pg_stat_activity, so operators can identify which DALP service owns a connection during incident triage or pool-capacity reviews.
Session and schema controls
DALP sets database sessions to UTC through PostgreSQL connection options. This keeps timestamp handling consistent across services and avoids host-local timezone drift.
Where a component needs a schema search path, DALP validates each schema identifier before passing it to PostgreSQL. The validation allows alphanumeric characters and underscores only. This prevents unsafe values from being injected into the session search_path option.
TLS modes
The database configuration supports PostgreSQL-style TLS modes:
| Mode | Effect in DALP's PostgreSQL client configuration |
|---|---|
disable | Connect without TLS. |
prefer | Use TLS without certificate verification; no plaintext fallback. |
require | Require TLS and verify the server certificate. |
verify-ca | Verify the certificate authority without hostname verification. |
verify-full | Verify the certificate authority and hostname through the TLS stack. |
A deployment can also provide CA certificate content or a CA file path. Certificate file paths are resolved inside the application directory to avoid directory traversal. Production deployments should choose the strictest mode supported by the target PostgreSQL service and network design.
Health and shutdown behaviour
The database loader exposes a health check that runs SELECT 1 through the configured pool. The check returns false when the loader has already been destroyed, when no usable pool exists, or when the query fails.
Shutdown closes the pool and clears cached database handles. Calling shutdown more than once is safe. Operators should wire service readiness and liveness checks to the deployment's health model instead of treating a process start as proof that PostgreSQL is reachable.
High availability
PostgreSQL availability is a deployment responsibility. DALP documents the data and connection behaviour the platform expects; the operator chooses the cluster pattern, failover mechanism, backup policy, and recovery targets.
Use the high availability page to select a cloud-native, hot-warm, hot-cold, or hot-hot operating pattern. The measured RTO and RPO come from restore drills and failover tests, not from this page.
Backup and recovery planning
A production database plan should define at least these facts:
| Planning item | Operator decision |
|---|---|
| Backup frequency | How often full, incremental, and write-ahead-log backups are captured. |
| Retention | How long operational, audit, and compliance records remain available. |
| Restore test cadence | How often the team proves that backups can restore a usable DALP environment. |
| RTO | The maximum acceptable time to restore the service after a database incident. |
| RPO | The maximum acceptable amount of data loss after a database incident. |
| Access during recovery | Which operators can restore, promote, or inspect the database during an incident. |
Point-in-time recovery and archive retention depend on the selected PostgreSQL service and backup tooling. Document the tested recovery path in the deployment runbook and compare actual restore time with the agreed RTO.
Security
Encryption
At rest encryption depends on the database hosting layer. Managed PostgreSQL services usually provide storage encryption and may support customer-managed keys. Self-managed deployments must configure storage encryption through the chosen infrastructure.
In transit encryption is controlled by the TLS mode above. Use certificate verification for production networks where the PostgreSQL service presents a trusted certificate.
Access control
Database access should be scoped by service account and operational role. Components should receive only the credentials and schema access they need. Administrative access should use the deployment operator's privileged-access process, including MFA and auditable approvals where required.
Audit logging
PostgreSQL audit logs can capture data access for deployments that enable database auditing. Retention, export, and SIEM routing depend on the deployment's logging storage, backup, and compliance configuration. See observability audit logging for the shared audit logging model.
See also
- Operability overview for the production evidence chain.
- Observability for database monitoring and audit-log routing.
- Failure modes for degraded database and dependency behaviour.
- High availability for RTO, RPO, failover, and restore planning.
Observability
The observability stack provides platform visibility through metrics collection, log aggregation, distributed tracing, and Grafana dashboards for deployments that enable the observability chart.
Failure Modes
Architecture-level failure-mode reference for DALP deployments, covering how platform components degrade, what operators can detect, and which recovery path applies when dependencies are unavailable.