Expand the "DataBase" project, and press on "view cost by service" in the bottom right

My memory usage shows 121,871.49 minutely GB, which is generating $28.21 in charges — this seems extremely high for my workload.

121,871gb minutely seems like a lot but its only a total of 2.8gb over the span of a month, that's about how much 6 databases would run you for

i dont have 6 databases

its only 1 database

I didn't mean to imply that you have 6 databases, I'm just putting it into perspective

I understand the perspective you’re giving, but I still need a precise explanation because something doesn’t add up on my end.

I did 3 calculations:

1. Pricing calculated based on your minutely memory usage (54400*60*0.00000386 = $12.59)

2. Pricing calculated based on the RAM usage visible on the graph (~1.4gb) (1.4*27*24*60*60*0.00000386 = $12.6)

3. Average ram usage based on minutely gb (54400/(60*24*27) = 1.4gb)

and it's all checking out fine for me, based on my math you used about 1.4gb average memory for 27 days, which if you calculate the cost of that comes out to 12.6usd

What's not adding up on your end?

Thanks for taking the time to calculate everything — I appreciate that.

What’s not adding up for me is why the average RAM usage is around 1.4 GB for a single database that should normally be extremely lightweight.

My actual workload on that database is very small

services can have memory leaks or generally high base memory usage

what database did you run?

Mysql

MySQL is anything but lightweight

MySQL is the biggest memory hog database I know

I'd highly suggest using MariaDB instead, it's a drop in replacement and is actually lightweight

so the issue is from Mysql itself ?

most likely yea

or rather, definitely, yea

Railway's job is to provide the hardware and resources for apps running in Railway to function
if MySQL tells Railway that it needs 1.4gb of memory to function, then Railway provides that memory

meaning to say, if resource usage is ever a problem, it's 99.999% of the time an issue with the app and not with any sort of Railway configuration

the only configuration that could help you here is restricting the resources allowed to the container but that would only result in MySQL crashing or performing poorly if it doesn't get the resources it needs

but I'd recommend using MariaDB instead, it's much better in terms of resource usage

i cant change to MariaDB it will take a lot of time

but please i wanna share something

one second

look this month

look how it was before

Yea that checks out for MySQL, its memory usage only increases over time from what I've seen

likely case is that back then it wasn't using as much memory as it does now

Unfortunately if you want to use MySQL on Railway, you'd need to face the resource consumption, that's just how MySQL runs

okay and sry for taking fron ur time

one last question

is there any approach that i can use to limit this high bill for the database ?

no worries

and yes

Railway Side:

• You can put account-wide usage limits which will stop all services when reached

• You can configure service-scoped resource restrictions, this should be visible in the service settings

• You can (and this is the recommended solution here) use MariaDB instead, which is in most situations a drop-in replacement

There's nothing much you can do on the MySQL side of things, Railway's MySQL already comes with all the optimisations I can think of like disabling log files and disabling performance monitors that uses a lot of resources

Here’s what I’d like to know:

Are there recommended MySQL configuration tweaks (timeouts, buffer sizes, background task settings) that Railway supports on shared or paid plans?

Are there known patterns with Prisma + Railway MySQL that can trigger histogram update lock waits?

Is there a way to inspect slow queries, locks, or I/O throttling on Railway’s side to confirm the root cause?

Can I perform specific tests or measurements (connection pooling, concurrency limits, read/write patterns) to better understand why histogram updates are timing out?

Is this behavior expected under certain workloads, or is it a sign that the database is approaching its operational limits?

I understand the suggestion to switch to MariaDB, but before making such a major change I want to be sure this is not something that can be solved by:

optimizing my ORM configuration,

adjusting query patterns,

or modifying some MySQL settings that Railway allows.

Any deeper guidance or recommended tests would be appreciated so I can confirm the real source of the issue. Thanks!

I can't answer many of these because I don't use MySQL and therefore wouldn't know, but I'll answer what I can

Are there recommended MySQL configuration tweaks (timeouts, buffer sizes, background task settings) that Railway supports on shared or paid plans?
I only know of 2, but they're enabled by default now: disabling binary logging and disabling performance monitors

Is this behavior expected under certain workloads, or is it a sign that the database is approaching its operational limits?
That's just the expected behaviour for any MySQL database running on Railway

okay thanks a lot

no problem at all

all clear to mark this as solved? @Fares

yes

awesome!