2 months ago
Hello Railway Support,
I’m on a Railway Pro subscription and I’m seeing a very large and unexpected increase in billing for a TimescaleDB service in one of my projects.
Service: TimescaleDB (in project)
Context: The storage/volume size hasn’t increased much over the past months, and I barely used this service recently.
Billing change was around 10 times. From the pricing breakdown it looks like the increase is primarily memory billing, while volume/storage billing remains normal. This is confusing because the database was not actively used this month.
Could you please help me understand:
What specifically caused the memory-billing increase (e.g., higher memory allocation, autoscaling behavior, background jobs, restarts, upgrades, extensions, or any platform-side changes)?
Whether there are recommended settings or actions to keep memory usage (and cost) much lower (e.g., tuning shared_buffers/work_mem, connection limits, background workers, Timescale policies, compression jobs, etc.) - or if the minimum memory tier for this service is driving the cost.
If there’s no reasonable way to keep it low: what’s the best way to export/download a full backup of this database so I can remove the TimescaleDB service from Railway?
If you need any additional details (service ID, billing period timestamps, metrics screenshots), tell me what to provide and I’ll send it.
1 Replies
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
a month ago
TimescaleDB (and Postgres in general) loves to grab memory and hold onto it even when you're not really using it. Background jobs like compression, retention policies, and maintenance workers run automatically and eat up RAM. Railway bills based on memory usage over time, so even an "idle" database can rack up costs if it's sitting there hogging memory.
What You Can Do
Check your service metrics to see actual memory usage. You can tune settings like shared_buffers, work_mem, and reduce max_worker_processes / timescaledb.max_background_workers to keep it leaner. Also set a memory limit on the service in Railway settings so it can't balloon.
If You Wanna Bail
Run pg_dump to export your database, you can do it via Railway's CLI or connect remotely and dump it locally. Once you got the backup, you can safely delete the service.
Might be worth posting your service ID so someone from Railway can actually peek at what triggered the spike.