Hi, there seems to be a commit linked to each memory increase. Could you share why you think the subscription is tied to the increase memory usage ? Furthermore, I would recommend reverting to a previous commit to see if the memory usage goes down.

This is not an issue we're aware of, but will investigate if we have a good reason to.

Best,
Nico

When I previously upgraded from hobby plan to pro plan, I saw that memory consumption increased and I switched back to hobby plan. This is happening now. Unfortunately, I have an application that uses 1 GB of memory and when I switch to pro plan, it increases to 2.5 GB. I don't know why this is happening. While I use 1 GB in hobby plan, it increases to 2.5 GB in pro plan. It seems to have decreased to 1.8 GB right now. It decreased after I wrote to you. I am attaching an example screenshot.

As I mentioned, there are commits that correlate to your higher usage. You might want to look into the changes made around those times to identify any increase in resource consumption.

I am also experiencing the same problem with DB. When I switch to a Pro account, memory consumption increases, but when I stay in the hooby plan, memory consumption decreases by half.

Last time I wrote this I got an answer saying that your usage increased because you made a change in your code. However I understood that this was not true by moving it to the hobby plan and testing it. I did not make any significant changes to my code. If you want, put my backend project back to the hooby plan and then you will see. If you want, put my backend project in the hobby plan for testing.

Hi Vacbid, sorry to hear you're experiencing this issue. Could you please do me a favor and make the switch, but do not make any code commit changes, or any other changes at all and send over screenshots / video recordings of what you are seeing in terms of the usage spikes stemming from just changing the plan?
If you can actually show the entire process -> usage charts before -> plan change was made (but no other change at all) -> usage increased in the charts, that would be super helpful!

I will transfer my backend project from pro account to hobby account without making any changes and I will send you all the screenshots. But how can I transfer my backend project from pro account to hobby account?

I’ve been working on and testing this for about a year. When I keep my projects on the Free or Hobby Plans, memory usage stays around 1GB. However, when I switch my projects to the 32GB Pro Plan, memory usage goes up to 3GB or more. I am not making any changes to the same projects and code. The same thing happens with my PostgreSQL project. As a result, when I switch to the Pro Plan, I am forced to pay more.

As you can understand, I am requesting a refund for the excess fees I’ve been paying over the past year. To confirm this issue, I waited on the Free Plan for a long time without making any code changes. Then, after switching to the Pro Plan, memory usage increased. I see this happening across all of my projects. Thank you in advance for your attention to this matter.

I am also sharing with you the screenshots of my PostgreSQL project, which I have been testing in the same way for about a year.

Looks like you downgraded to Hobby smoothly — thank you! I'll look into your metrics and see what's going on.

A few days ago I redeployed the database and my memory consumption dropped from 8 GB to 1 GB. Similarly, when I redeployed it a day ago, my memory consumption increased to 6 GB without any change. I cannot make sense of the difference here. I check all the logs. However, I cannot draw any meaningful conclusion. Also, I am using it on a website that does not receive any hits. I cannot solve the problem. Why is it consuming around 7 GB of memory?

I cannot make sense of the difference here.

I'm afraid we can't help you with this here. There's nothing we can find that would cause issues similar to yours.

We measure resource consumption, we tell you how much you use, and we bill you for it. There is no difference between plans - Pro simply increases your resource limits (in this context) giving you more to use. It does not cause or incur additional usages unless your workload uses it.

We cannot tell you why you're using a certain amount of resources, similar to how your utilities provider cannot tell you why you're using X amount of electricity or water. Resource consumption is heavily dependent on what you're doing with your instance - you might have low traffic but run some background jobs, or you have an issue where you're not garbage collecting properly, or Postgres might be caching some heavy queries for you (this is plausible because memory goes down on redeploy).

It's impossible for us to tell you why because there are an unbounded number of variables involved leading to many different scenarios that could explain it. I'd recommend looking into instrumentation and telemetry if you're concerned about this

Actually, I am asking this. When I deploy my same postgre sql container once, I see that it uses 1gb ram and I am sending a screenshot of this. Again, when I deploy my same postgre sql file without any changes, I see that it uses 7gb ram. I cannot explain the reason for this either because everything including the logs is the same as the old deploy. What could have happened in the past 24 hours? Also, one of the main reasons why we prefer companies like Railway as all software developers is to find answers to such issues. Otherwise, we would have to start a server, deal with the devops side and look for answers to this. Unfortunately, there seem to be two different problems. 1. My same java application, which consumes 2gb and more in pro, consumes 1gb in hobby plan. 2. I am experiencing the problem in postgre. When I try to do a vacuum I get the error [53100] ERROR: could not resize shared memory segment "/PostgreSQL.1354157574" to 67129376 bytes: No space left on device. I would be glad if you could fix this.

> 1. My same java application, which consumes 2gb and more in pro, consumes 1gb in hobby plan.

This could be due to the Java JVM seeing more available memory and thus deciding it can use more memory, can you try setting Xms and Xmx to fixed values?

> 2. I am experiencing the problem in postgre. When I try to do a vacuum I get the error [53100] ERROR: could not resize shared memory segment "/PostgreSQL.1354157574" to 67129376 bytes: No space left on device.

This is due to the default SHM size of the container being smaller than what Postgres needs for that vacuum command, you can increase the SHM size by setting a service variable RAILWAY_SHM_SIZE_BYTES to 134217728 (128MB)

Hello, I understand the first solution and will try to implement it. Additionally, I have added a new variable to the Environment Variables for the second solution and will try what you suggested.

If you experience this it's likely due to the instance thinking it's got more resources than it actually has

If you don't care about the extra performance, you can turn down the vCPU and memory in service settings