Heya, there are no known issues.

Are these the same queries you used to run on azure? do you have an example query we can look at?

I'm happy to raise this up as queries should definitely not take that long on railway.

It sporadically seems to affect all of my queries. For example I might have a query like select * from my_table LIMIT 50 and usually it's fine but sometimes I have seen it take 30 seconds. The entire table has like 100 rows in it.

I believe it's either that I have misconfigured something (although I haven't really touched anything from the default template) or there is some slowdown w/ postgres interacting with my volume.

that should definitely work out of the box, let me raise that for you.

Hello!

We've escalated your issue to our engineering team.

We aim to provide an update within 1 business day.

Please reply to this thread if you have any questions!

I think maybe you fixed something on your end? Seems to be working better now

Hi there, glad things are running smoother!

If you notice sporadic slowdowns creeping back in, a couple of things worth checking: make sure your application and PostgreSQL database are in the same region to keep latency low, and keep an eye on your database's resource usage through the service metrics and definitely let us know if anything changes or if you hit any other snags.

Best, The Railway Team

🛠️ The ticket Slow database queries has been marked as backlog.

Hey there, I'm getting reports from my customers that they are seeing timeouts occasionally. I am looking at my postgres logs and I do see that some very basic queries are taking upwards of 25 seconds.

Is this something you can help debug? I really don't think it's on my end (ofc I could be wrong) but I wasn't seeing this with my azure managed postgres. Resource usage looks very mild.

Noted, I am going to migrate non commercial workloads off the machine the DB is on to see if that helps with performance.

I think it may be slow disk writes. For example I see this in my logs
{"message":"2026-02-04 05:57:20.614 UTC [28] LOG: checkpoint complete: wrote 313 buffers (0.5%); 0 WAL file(s) added, 0 removed, 0 recycled; write=31.391 s, sync=0.010 s, total=31.458 s; sync files=28, longest=0.010 s, average=0.001 s; distance=1866 kB, estimate=1866 kB; lsn=D/28492240, redo lsn=D/284921B0","attributes":{"level":"error"},"timestamp":"2026-02-04T05:57:30.480821911Z"}

31 seconds to write <2MB seems like something is wrong with slow i/o

Our logs confirm elevated checkpoint write times and slow INSERTs to your context_message table (15-30 seconds), along with statement cancellations around Feb 3. That said, the machine is now calm- are you still seeing the slowdown?

I made some configuration changes on my end to try and smooth out the load for my end users as a stop-gap solution. Specifically setting synchronous_commit to 'off'. But it really does feel like the write performance is just generally bad. For example:

{"message":"2026-02-06 02:46:36.141 UTC [28] LOG:  checkpoint starting: time","attributes":{"level":"error"},"timestamp":"2026-02-06T02:46:36.887908693Z"}

{"message":"2026-02-06 02:46:46.790 UTC [28] LOG:  checkpoint complete: wrote 95 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=9.473 s, sync=0.973 s, total=10.650 s; sync files=22, longest=0.971 s, average=0.045 s; distance=516 kB, estimate=516 kB; lsn=D/39F5BD50, redo lsn=D/39F53778","attributes":{"level":"error"},"timestamp":"2026-02-06T02:46:46.874452191Z"}

{"message":"2026-02-06 02:49:36.890 UTC [28] LOG:  checkpoint starting: time","attributes":{"level":"error"},"timestamp":"2026-02-06T02:49:39.301301555Z"}

{"message":"2026-02-06 02:49:43.190 UTC [28] LOG:  checkpoint complete: wrote 64 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=6.252 s, sync=0.017 s, total=6.301 s; sync files=19, longest=0.016 s, average=0.001 s; distance=340 kB, estimate=499 kB; lsn=D/39FAA0A0, redo lsn=D/39FA89E8","attributes":{"level":"error"},"timestamp":"2026-02-06T02:49:43.268094568Z"}

{"message":"2026-02-06 02:52:36.289 UTC [28] LOG:  checkpoint starting: time","attributes":{"level":"error"},"timestamp":"2026-02-06T02:52:36.911549587Z"}

{"message":"2026-02-06 02:52:39.195 UTC [28] LOG:  checkpoint complete: wrote 29 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=2.833 s, sync=0.022 s, total=2.907 s; sync files=18, longest=0.020 s, average=0.002 s; distance=123 kB, estimate=461 kB; lsn=D/39FC7848, redo lsn=D/39FC77F0","attributes":{"level":"error"},"timestamp":"2026-02-06T02:52:39.767332577Z"}

This is very slow no? I would expect << 1 second to write these checkpoints.

Hmm, that is a bit odd but not entirely unheard of. I don't see much on our end specifically with that host your database is on that would lead to this. Is this something sudden? Does it coincide with times of high traffic or usage on the database?

Thanks for looking, this has been happening fairly consistently (every day) since migrating my postgres from Azure. Does not seem to coincide with spikes in traffic, it's a fairly low traffic service. I can try to do more diagnostics and add more logs in postgres but it really feels like a slow storage device or IOPs getting limited or something like that.

If you did have any details on the specific area its running into issues on that'd be great. Don't have too much pointing to issues here but don't want to discount it because of that