Add PostgreSQL 18 support and make it the default image version

[Copilot]

This updates the image matrix to include PostgreSQL 18 and promotes it to the default published/runtime target. It also aligns local compose usage and documentation with the actual build arguments used by the image.

• Version matrix

  • add 18.3 to versions.json
  • mark PostgreSQL 18 as latest
  • keep existing PostgreSQL 17/16/15/14 entries intact

• Default image target

  • update the Dockerfile default from PostgreSQL 17 to 18.3
  • this makes the default build track the new supported major

• Compose alignment

  • normalize compose build args to the names the Dockerfile actually consumes:
    • PG_VERSION
    • POSTGIS_VERSION
    • PGVECTOR_VERSION
  • update defaults to PostgreSQL 18.3, PostGIS 3.6.2, pgvector 0.8.2
  • switch the test client image to the major tag (postgres:18) so local test composition does not depend on a patch-tagged client image existing

• Documentation

  • refresh example image tags and local override examples for PostgreSQL 18
  • document the current build-arg contract and clarify that these values are build-time inputs unless explicitly provided again at runtime

services:
  db:
    build:
      context: .
      args:
        PG_VERSION: ${PG_VERSION:-18.3}
        POSTGIS_VERSION: ${POSTGIS_VERSION:-3.6.2}
        PGVECTOR_VERSION: ${PGVECTOR_VERSION:-0.8.2}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add PostgreSQL 18 support and make it the default image

✨ Enhancement 🐞 Bug fix ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

AI Description

• Add PostgreSQL 18.3 to the build matrix and make it the published latest version.
• Align local Compose build arguments with the Dockerfile and use the PostgreSQL 18 client major
 tag.
• Refresh image examples and clarify that version build arguments are not automatically runtime
 variables.

Diagram

graph TD
  V["Version matrix"] --> T["CI tests"] --> D["Docker build"] --> B["Postgres base"]
  V --> P["Publish workflow"] --> G[("GHCR images")]
  C["Local Compose"] --> D
  CT["Test Compose"] --> D
  CT --> B
  P --> D

Loading

High-Level Assessment

Extend the existing version matrix and use the Dockerfile's existing argument names. This preserves older combinations without changing the CI or publishing workflows; generating defaults from the matrix would add machinery for little benefit.

Files changed (5) +32 / -28

Enhancement (2) +8 / -2

DockerfileDefault builds to PostgreSQL 18.3 +1/-1

Default builds to PostgreSQL 18.3

• Changes the default PostgreSQL base-image version from 17.9 to 18.3. The PostGIS and pgvector defaults remain unchanged.

Dockerfile

versions.jsonAdd PostgreSQL 18.3 as the latest matrix entry +7/-1

Add PostgreSQL 18.3 as the latest matrix entry

• Adds PostgreSQL 18.3 with the existing PostGIS and pgvector versions and marks it as latest. Retains PostgreSQL 17.9 and the older supported entries, marking 17.9 as no longer latest.

versions.json

Bug fix (2) +7 / -9

docker-compose.test.ymlAlign test builds and client image with PostgreSQL 18 +4/-4

Align test builds and client image with PostgreSQL 18

• Passes the version arguments consumed by the Dockerfile, defaulting to PostgreSQL 18.3, PostGIS 3.6.2, and pgvector 0.8.2. Defaults the test client to the PostgreSQL 18 major tag while retaining a separate 'PG_MAJOR' override.

docker-compose.test.yml

docker-compose.ymlCorrect local Compose build arguments and defaults +3/-5

Correct local Compose build arguments and defaults

• Replaces obsolete build-argument names with the three names consumed by the Dockerfile and sets current version defaults. Removes the inaccurate comment claiming those arguments become runtime variables.

docker-compose.yml

Documentation (1) +17 / -17

README.mdDocument current image tags and build arguments +17/-17

Document current image tags and build arguments

• Updates the published-tag example, build and Compose overrides, and local test command for the current version scheme. Clarifies that version build arguments are not automatically available as runtime environment variables.

README.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. PostgreSQL 17 data is not persisted ✓ Resolved

Description

docker-compose.yml mounts postgres_data at /var/lib/postgresql, but the PostgreSQL 17 base
image declares a separate volume at /var/lib/postgresql/data, so database writes go to an
anonymous child volume instead of the named one. When a PostgreSQL 17 container is removed and
recreated, such as after docker compose down, the new container does not reuse those database
files; the updated docker run example has the same issue.

Code

docker-compose.yml[18]

+      - postgres_data:/var/lib/postgresql

Evidence

The Dockerfile selects the official base image using PG_VERSION, and the version matrix retains
PostgreSQL 17.9. The changed Compose mount targets the parent of the older image's declared data
volume; Docker mounts that declared child volume separately, masking the named parent mount at the
database path. The README also identifies /var/lib/postgresql/data as the former PostgreSQL 17
mount path.

Dockerfile[2-6]
versions.json[8-12]
docker-compose.yml[17-18]
README.md[55-59]
README.md[106-106]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new parent-directory mount persists PostgreSQL 18 data, but PostgreSQL 17 and earlier declare a child volume at `/var/lib/postgresql/data`. Their database files therefore go to an anonymous volume rather than the named parent volume.
## Fix Focus Areas
- docker-compose.yml[18-18]
- README.md[55-59]
- README.md[75-76]
## Recommended Fix
Provide a version-specific mount or data-directory configuration that puts PostgreSQL 17 and earlier database files on the named volume while retaining the parent mount for PostgreSQL 18. Update both README examples and remove the claim that the unchanged parent mount persists older versions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Recreated databases lose their data ✓ Resolved

Description

docker-compose.yml defaults the build to PostgreSQL 18.3 but still mounts postgres_data at
/var/lib/postgresql/data, while the official PostgreSQL 18 image stores its cluster under
/var/lib/postgresql/18/docker. With the default Compose configuration, database writes miss the
declared persistent volume, so recreating the container does not restore its data; the README’s
docker run example uses the same outdated mount path.

Code

docker-compose.yml[6]

+        PG_VERSION: ${PG_VERSION:-18.3} # Environment variable PG_VERSION, defaults to 18.3

Evidence

The Dockerfile selects the official PostgreSQL image using PG_VERSION, and Compose now passes 18.3
by default. Its named volume remains mounted at /var/lib/postgresql/data, which does not cover
PostgreSQL 18's default cluster path, /var/lib/postgresql/18/docker; the documented manual run
mounts the old path too.

Dockerfile[2-6]
docker-compose.yml[6-18]
README.md[49-57]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new PostgreSQL 18 default writes its cluster outside the persistent volume mounted by Compose. The README's `docker run` example has the same mount path.
## Fix Focus Areas
- docker-compose.yml[6-18]
- README.md[49-57]
## Recommended Fix
Mount the volume at `/var/lib/postgresql` for PostgreSQL 18 and update the README example to match. Document how existing PostgreSQL 17 volumes should be migrated rather than treating a mount-path change as an automatic major-version upgrade.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Readers cannot pull the example image ✓ Resolved

Description

The README names an 18.3/3.6.2/0.8.2 image tag, but the publish workflow constructs tags only from
combinations in versions.json, which lists PostgreSQL 18 as 18.6/3.6.4/0.8.6. After a release,
readers who copy the new PostgreSQL 18 example request a tag this repository does not publish.

Code

README.md[17]

+- `ghcr.io/yourusername/yourrepositoryname:postgres-18.3-postgis-3.6.2-pgvector-0.8.2`

Evidence

The only PostgreSQL 18 matrix entry contains 18.6, 3.6.4 and 0.8.6; the publishing workflow
generates version-specific tags from those matrix fields. The README's newly added tag instead
contains 18.3, 3.6.2 and 0.8.2.

README.md[15-18]
versions.json[2-13]
.github/workflows/publish.yml[99-110]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The README's PostgreSQL 18 example uses a version combination absent from the publishing matrix, so the example tag is not published.
## Fix Focus Areas
- README.md[15-18]
- versions.json[2-7]
## Recommended Fix
Change the example tag to `postgres-18.6-postgis-3.6.4-pgvector-0.8.6`, matching the PostgreSQL 18 matrix entry and the publish workflow's tag format.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Recreated databases lose their data 🐞 Bug ☼ Reliability

docker-compose.yml defaults the build to PostgreSQL 18.3 but still mounts postgres_data at
/var/lib/postgresql/data, while the official PostgreSQL 18 image stores its cluster under
/var/lib/postgresql/18/docker. With the default Compose configuration, database writes miss the
declared persistent volume, so recreating the container does not restore its data; the README’s
docker run example uses the same outdated mount path.

Agent Prompt

## Issue description
The new PostgreSQL 18 default writes its cluster outside the persistent volume mounted by Compose. The README's `docker run` example has the same mount path.

## Fix Focus Areas
- docker-compose.yml[6-18]
- README.md[49-57]

## Recommended Fix
Mount the volume at `/var/lib/postgresql` for PostgreSQL 18 and update the README example to match. Document how existing PostgreSQL 17 volumes should be migrated rather than treating a mount-path change as an automatic major-version upgrade.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[naorpeled]

@copilot fix the issue, but make sure ro not break previous versions' runs

[Copilot]

@copilot fix the issue, but make sure ro not break previous versions' runs

Fixed in e6ba5ba. The compose volume and README examples now mount /var/lib/postgresql for PostgreSQL 18, and I validated that the same parent-directory mount still works with PostgreSQL 17 so older runs are not broken.

[naorpeled]

/agentic_review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit e6ba5ba

[naorpeled]

/agentic_review

[naorpeled]

@copilot address Qodo's feedback

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 5f8c2d7

[Copilot]

@copilot address Qodo's feedback

Addressed in 254d883. I aligned the PostgreSQL 18 defaults/examples with the current matrix entry and changed the local compose/runtime setup to use PGDATA=/var/lib/postgresql/pgdata, which I verified persists correctly across container recreation for both PostgreSQL 17.9 and 18.6.