|
| 1 | +# PostgreSQL Logical Module |
| 2 | + |
| 3 | +  |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +This flavour creates **no cloud resources**. It models a **logical database |
| 8 | +hosted on an existing/shared PostgreSQL instance** (selected via `spec.source`): |
| 9 | +a pure passthrough that re-exposes that instance's connection outputs under the |
| 10 | +`@facets/postgres` contract. |
| 11 | + |
| 12 | +The primary use case is **staging DB consolidation**: a logical database |
| 13 | +co-located on a shared physical instance. A blueprint can declare one logical |
| 14 | +`postgres` resource per service while each one points at the same shared |
| 15 | +instance — optionally re-targeting the connection string at a different logical |
| 16 | +database name. |
| 17 | + |
| 18 | +## Resources Created |
| 19 | + |
| 20 | +None. `main.tf` declares no resources and no providers. The module is a |
| 21 | +stateless transform over `var.instance.spec.source`. |
| 22 | + |
| 23 | +## Spec |
| 24 | + |
| 25 | +| Field | Type | Required | Notes | |
| 26 | +|-------|------|----------|-------| |
| 27 | +| `source` | `@facets/postgres` (via `x-ui-output-type`) | yes | The existing/shared postgres instance hosting this logical database. Resolves to the selected resource's full outputs (interfaces + attributes). Selectable per environment, so it is override-able. | |
| 28 | +| `database_name` | string | no (override-only) | Logical database to target on the shared host. When set, the `connection_string` is rebuilt to point at this database; otherwise the source connection string passes through unchanged. | |
| 29 | + |
| 30 | +## Outputs |
| 31 | + |
| 32 | +Emits `@facets/postgres` with `reader` and `writer` interfaces |
| 33 | +(`host`, `port`, `username`, `password`, `connection_string`, `secrets`) |
| 34 | +carried over from the source. Any source `attributes` (e.g. |
| 35 | +`db_instance_identifier`, `arn`) are passed through. This matches the output |
| 36 | +contract of `aws-rds` and `aws-aurora`, so consumers cannot tell the |
| 37 | +difference between a dedicated instance and a logical database. |
| 38 | + |
| 39 | +## Connection string re-targeting |
| 40 | + |
| 41 | +When `database_name` is set, both reader and writer `connection_string` |
| 42 | +values are rebuilt as: |
| 43 | + |
| 44 | +``` |
| 45 | +postgres://<source-username>:<source-password>@<source-host>:<source-port>/<database_name> |
| 46 | +``` |
| 47 | + |
| 48 | +Credentials, host and port are inherited from the source; only the database |
| 49 | +path segment is replaced. When `database_name` is unset, the source's own |
| 50 | +`connection_string` is passed through verbatim. |
| 51 | + |
| 52 | +## Use case: staging DB consolidation |
| 53 | + |
| 54 | +In staging it is common to run a single shared physical PostgreSQL instance |
| 55 | +and give each service its own logical database. Model this by: |
| 56 | + |
| 57 | +1. Deploying one real postgres datastore (e.g. `aws-rds`) — the shared instance. |
| 58 | +2. Adding a `postgres/logical` resource per service, with `spec.source` |
| 59 | + pointing (per environment, via `--flavor`/override) at the shared instance |
| 60 | + and `database_name` set to the service's logical database. |
| 61 | + |
| 62 | +This keeps blueprints identical across environments while consolidating |
| 63 | +physical infrastructure in non-production. |
0 commit comments