Heya, not sure what you mean by connections at user levels;

We've seen plenty of customers scale databases on railway to large customer bases.

At very high loads you'll probably want to look into making your DB HA into multiple regions or maybe add something like pgbouncer to manage your connection pools - but a single Postgres DB can scale a lot

You can self-grow the volumes up to 250gb - after that just send us a support request and we can bump it further (we have a few customer with 2TB+ volumes)

Hope this helps !

-Nico

Dear Nico,

Thank you for your prompt response and the valuable information regarding PostgreSQL storage capacity and scalability on the Railway Pro plan. Your insights about scaling volumes up to 250 GB and the possibility of increasing beyond 2 TB with support assistance are very helpful as we plan for our SaaS platform’s growth. I’d like to clarify a few points and request additional details to better understand how Railway can support our project’s needs.

To clarify my previous question about “connections at user levels,” I meant that we expect approximately 20% of our total users to be concurrently connected at any given time. Specifically, we are evaluating the following scenarios: 500 users (100 concurrent connections), 1,000 users (200 concurrent connections), 10,000 users (2,000 concurrent connections), and up to 50,000 users (10,000 concurrent connections). With this in mind, I have the following questions:

1. Storage Costs for Volumes >250 GB:

   • You mentioned that volumes can be self-scaled to 250 GB, and beyond that, we can contact support for larger volumes (e.g., 2 TB+). Could you provide details on the pricing structure for storage beyond 250 GB? For example, is there a cost per GB or TB, and are there any additional fees for requesting a volume increase? This information is critical for us to quantify cloud storage costs and set pricing for our subscription-based SaaS platform.

   • Additionally, I noticed in the Railway dashboard that there’s an option to increase volume size graphically. Does scaling volumes through the UI incur the same costs as requesting a manual increase via support? If so, could you confirm the cost per GB for volumes above the default 50 GB?

2. PgBouncer Configuration:

   • You recommended using PgBouncer to manage connection pools for high loads, which is great advice given our projected concurrent connections (up to 10,000). Could you share guidance on how to set up and configure PgBouncer within a Railway project? For instance, is there a recommended way to deploy PgBouncer as a service in Railway, and are there any best practices or documentation for integrating it with our PostgreSQL database?

   • Does Railway provide built-in tools or metrics to monitor PgBouncer performance, such as connection pool usage or latency?

3. High Availability (HA) Support in the Pro Plan:

   • You suggested making the database HA across multiple regions for very high loads. Could you clarify whether the Pro plan supports HA configurations out of the box, or if this requires a custom setup? If it’s supported, what are the steps to enable HA, and are there additional costs associated with running replicas in multiple regions?

   • Are there specific Railway features or tools to manage failover and replication for HA setups?

4. Interface for Database Configuration Commands:

   • Regarding the command ALTER SYSTEM SET max_connections = 200; to increase concurrent connections, could you confirm the recommended interface for executing this command on Railway’s PostgreSQL database? For example, should we run it through a SQL client connected to the database, or is there a specific Railway CLI or dashboard feature for applying such configurations?

   • After executing this command, you mentioned a deployment restart is needed. Does this cause downtime, and if so, how can we minimize its impact?

Thank you again for your support. These details will help us make informed decisions about scaling our SaaS platform on Railway and accurately project our cloud infrastructure costs. I look forward to your response.

Best regards,
Jairo Massard

• Volume costs beyond 250GB are the same

• You'll need to go learn how to use PGBouncer yourself, this support channel won't be able to help you there. (There are plenty of tutorials and docs online!)

• No, you'll have to manage the database yourself if you want an HA setup.

• When you run postgres commands you need to use psql or a gui that can run psql commands

• Redeployments will only cause downtime in that it will force your database connections to reset to the new deployment after it is live. Railway deployments are blue/green by default.

Dear Railway Support team,

Thank you for your previous assistance with our requetss. In our project, Gestion_Empresarial, on Railway. I’m reaching out to clarify some details about storage costs and metrics to help us accurately project costs for our SaaS platform.

1. Storage Cost Confirmation:

You mentioned that "volume costs beyond 250 GB are the same." Does this mean the cost is $0.25/GB for all storage, including the base 50 GB, volumes between 50-250 GB, and up to 2 TB+? Are there any additional fees for requesting support to increase volumes beyond 250 GB?

2. Discrepancy in Volume Metrics:

The Railway dashboard reports a Postgres volume of 11112.95 GB costing $0.0643 for our project, Gestion_Empresarial. However, a query shows the actual database size as 26 MB. Is this a display error (e.g., KB reported as GB, or GB-hours instead of GB)? Could you confirm the actual storage used and how it aligns with the $0.25/GB pricing?

These clarifications are critical for planning our SaaS pricing and scaling strategy. Thank you for your support, and I look forward to your response.

Best regards,

Jairo Massard

No, the costs are the same. We just require that you request for larger sizes beyond 250GB.

The maximum volume size and your current database size on disk can be different. Storage cost is based on what usage you have. (Currently 1.15GB).