Hi Railway community,

I'm running into a persistent collation version mismatch warning in my PostgreSQL database hosted on Railway. I'm using the default PostgreSQL template provided by Railway (version 17), and this issue surfaces when I try to initialize Directus in my project.

Error Details

The logs show repeated warnings like this:

text2025-08-17 07:08:24.557 UTC [87] WARNING: database "postgres" has a collation version mismatch.

2025-08-17 07:08:24.557 UTC [87] DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

2025-08-17 07:08:24.557 UTC [87] HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

This happens multiple times, especially during database operations triggered by directus init. I've attached a screenshot of the logs for reference.

What I've Tried So Far

1. Connected to the DB via psql and ran:

textALTER DATABASE postgres REFRESH COLLATION VERSION;

Followed by restarting the database service in the Railway dashboard. The warning persists on subsequent operations.

2. Considered rebuilding affected objects with REINDEX DATABASE postgres; but I'm hesitant as it might lock the DB temporarily, and I want to confirm if it's necessary.

3. Checked Railway docs and general PostgreSQL resources (e.g., Stack Overflow, PostgreSQL forums), which point to glibc updates on the host OS causing this mismatch.

My setup:

PostgreSQL version: 17 (from Railway template)

Project: Using Directus for headless CMS, initialized after deploying the DB.

No custom collations; everything is default.

Questions

1. Has anyone else encountered this with the Railway PG template? Is this due to underlying OS updates on Railway's side (e.g., glibc from 2.36 to 2.41)?

2. Would deploying a new PostgreSQL service directly from the official postgres:17 Docker Hub image (instead of the template) resolve this? If so, any tips on migrating data without downtime?

3. What's the best long-term fix? Should I create a fresh DB instance and migrate, or is there a Railway-specific workaround?

Any impact on production? So far, it's just warnings, but worried about subtle sorting/comparison issues.

Appreciate any insights or similar experiences—thanks in advance!