Roadmap relationship
Outcome
Represent databases and caches as first-class services with provider-aware provisioning, credentials, connection guidance, status, metrics, lifecycle actions, and safe migration between plans or targets.
Current gap
AWS clients and infrastructure builders cover RDS/Aurora/DynamoDB/ElastiCache, server drivers can provision some on-box databases, and the dashboard can create local databases/users. Meanwhile most db:* CLI commands are placeholders and engine capabilities, credentials, external exposure, password rotation, logs, performance, and lifecycle differ across paths.
User experience
- Create data services through a guided form for engine/version, provider/placement, size/storage, HA, backups, network exposure, maintenance, and cost drivers.
- Detail pages show endpoint type, engine/version, health, size/storage, connections, latency/IO/cache metrics, backups, users/credentials metadata, and dependent services.
- Connection panels provide copyable internal/external/tunnel commands with secret reveal requiring recent auth; never expose credentials by default.
- Resize, restart, rebuild, rotate password, expose/close port, clone, and delete display downtime/data-loss implications and capability support.
- Unsupported engines/actions are explained rather than presented as generic failures.
Scope
- Define a data-service capability model for managed AWS services and server/container-hosted Postgres, MySQL/MariaDB, MongoDB, Redis, and libSQL where drivers support them.
- Implement create/list/get/update/restart/delete, version/plan change, user/database management, password rotation, internal/external endpoints, SSH tunnel, logs/slow queries, and metrics as applicable.
- Track dependencies and inject connection secret references into applications without plaintext copy.
- Add import/adopt flow for existing managed resources with read-only plan preview before management.
- Expose CLI/API/dashboard parity and route mutations through durable operations.
Technical direction
- Use per-engine adapters behind shared lifecycle schemas and explicit capability descriptors.
- Keep desired configuration, credential references, and observed provider/runtime state separate.
- Use security-group/firewall/proxy primitives for exposure and generate least-privilege network rules.
- Coordinate resize/version/password work with backup, maintenance window, health checks, and dependent releases.
Safety and operability
- Deletion defaults to final snapshot/backup where supported and requires typed service-name confirmation plus retention choice.
- Credentials are generated strongly, stored in the configured secret backend, revealed once/recent-auth only, and rotated atomically where possible.
- Public exposure is off by default, warns on broad CIDRs, and never bypasses firewall reconciliation.
- Major version and destructive storage changes require preflight compatibility and backup.
Acceptance criteria
- At least managed Postgres/Aurora, on-box Postgres/MySQL, and Redis paths implement coherent create/connect/observe/backup/delete workflows.
- Capability differences are visible before an action is submitted.
- Rotating a credential updates references safely and reports dependent services needing redeploy.
- An adopted resource is not modified until an explicit reviewed change.
Verification
- Per-engine adapter contract tests plus credential, exposure, rotation, resize, version, and deletion-preflight tests.
- Authorization and secret non-disclosure tests across UI/API/logs.
- End-to-end create → connect → observe → rotate → backup → delete/retain workflow.
Non-goals
- Implementing every database engine on every provider.
- Providing a full database query IDE.
- Automatically migrating application schemas during infrastructure changes.