Can you provide more information about the endpoints that are seeing this or any additional details that might help us investigate? Where are the requests coming from?

here you have the example

[GIN] 2026/03/08 - 11:11:47 | 500 | 134.497µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 491.896µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 383.144µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 101.9µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 95.131µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 122.025µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 125.786µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:11:48 | 500 | 398.742µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:00 | 200 | 45.428416ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:06 | 500 | 295.522µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 122.117µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 124.978µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 128.781µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 115.121µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 106.579µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 500 | 144.258µs | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:08 | 200 | 28.579872ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:12:59 | 200 | 33.009675ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:13:00 | 200 | 54.270643ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:13:00 | 200 | 32.161133ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:13:00 | 200 | 40.100371ms | 79.144.85.162 | GET "/api/v1/user/profile"

[GIN] 2026/03/08 - 11:13:00 | 200 | 44.625169ms | 79.144.85.162 | GET "/api/v1/user/profile"

the request coming from my IOS APP, all de IP is the same (mine) as you can see some of the request are responding with 500 due to de timing

I have done some changes on my side to see if that fix the issue

Sounds good, let us know if the issue persists after your changes.

I’m seeing repeated PostgreSQL warnings in production about a collation version mismatch on my managed database.

The warning says:

WARNING: database "railway" has a collation version mismatch

DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.

HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE railway REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Context:

- This is happening on my production Railway Postgres instance

- I’m not sure whether this is expected after an underlying image / OS / libc upgrade on the provider side

- I want to understand whether Railway recommends any action from my side, or if this indicates an infrastructure-level change that should be handled carefully

My questions:

1. Is this a known / expected condition on Railway-managed Postgres?

2. Do you recommend I run ALTER DATABASE ... REFRESH COLLATION VERSION myself?

3. Do I need to rebuild indexes or other collation-dependent objects manually?

4. Is there any Railway-specific guidance to handle this safely in production?

At the moment the app is still working, but I want to avoid subtle issues in text ordering/comparisons or index behavior.

Thanks.

looking at your logs the 500s are failing in microseconds which means your app isn't even reaching the database, it's failing before that. this lines up with your collation mismatch warning. the warning itself tells you exactly what to do: run ALTER DATABASE railway REFRESH COLLATION VERSION. that said since this is a managed railway postgres instance i'd recommend opening a support ticket with railway before doing anything, ask them if they already handled the reindex on their end after the libc upgrade, because if they didn't and you have text indexes, you may need a REINDEX DATABASE too but don't run that without confirming with them first as it locks tables

facing same issues.