How PaaS Billing Works: Estimate Compute, Database, Storage, and Bandwidth Costs
TL;DR
-
Your monthly hosting bill is more than a single instance price. It covers compute for every service you run (such as your web app, workers, database, cache, and queue), along with storage, bandwidth, build minutes, and a monthly plan fee.
-
Providers meter compute either by the instances you keep running or by the resources each request consumes. With always-on instances, your bill covers the full time they stay provisioned, including idle time between jobs or requests.
-
Model both your expected baseline and a traffic spike in a cost worksheet so you can see which services scale with load before you deploy.
-
On Render, the web service, the worker, and the database run in one workspace, so you estimate the whole app in one place. You choose the instance size and how many instances stay on, so you can calculate the compute baseline before traffic grows. Storage and public bandwidth are separate lines. Services in the same workspace and region talk over a private network, and that traffic has no bandwidth charge. The API can reach the database without a NAT gateway or a cross-zone fee.
A developer asking whether hosting costs "$7/month" is looking at just one component of a possible bill. That advertised entry price rarely reflects the true cost of a production application operating a database and worker queue.
This article shows how to estimate that full bill. You will see which charges to include, how providers meter compute, and a worksheet to calculate your baseline and peak costs. It then walks through three workload patterns on Render: a worker-heavy app, a database-heavy app, and a high-traffic API.
What do you add up on the bill?
An advertised instance price is one line on the bill. You usually add up these lines:
- A monthly plan fee
- Compute
- Storage
- Outbound transfer
- Builds
Some hosts charge a monthly plan fee for your workspace, which is the shared team environment that groups your services and billing, rather than charging a plan fee per service. On Render, the Hobby plan has no monthly fee.
Compute covers the CPU and memory that run each service in your stack, such as your web app, background workers, database, cache, and queue. Stopping a service stops its compute charge, while any persistent storage attached to your app continues to bill until you delete it.
Storage covers persistent data across your stack. Count database volumes and any persistent disks attached to your services as separate line items based on the gigabytes you provision each month.
Outbound transfer is data sent off the platform. Hosts often include a monthly amount, then charge for the rest. On Render, private-network traffic between services in the same workspace and region has no bandwidth charge. Use the destination's internal address so the connection takes that path. Traffic on the public internet follows the host's outbound rules.
Builds are the minutes a host spends building and deploying your app, when it meters those minutes. They often include a monthly amount. They are separate from the compute that serves requests.
How is the compute line billed?
Providers generally bill compute in one of two ways:
- Always-on instances
- Usage-based compute
With always-on instances, you choose the instance size and how many instances stay running. You pay for the total time those instances remain available, including time spent waiting for the next request or job. You chose that capacity, so you can budget it. On Render, paid web services and background workers are billed by the second. A worker that stays up between jobs is billed while it waits for the next one, so count each running instance.
With usage-based compute, the host measures what the app uses. That can be CPU, memory, requests, or how long a run lasts. Check which of those it counts. Waiting is not always free. AWS App Runner charges for memory kept ready between requests. While a request runs, it also charges for CPU, and for any memory above that ready amount. Also check how long one run may last. Vercel Functions have a configured maximum duration. If the job needs longer, add a worker, and any queue it uses, to the estimate.
When comparing providers, model your workload under both always-on and usage-based compute, then add storage, bandwidth, and build costs to see the full total.
How do you build a cloud hosting cost estimate?
Start with service counts, running time, storage, and traffic. Use these checks to identify the charges your worksheet needs:
-
Add a usage charge only when that host bills for it. Outbound transfer and builds are the usual ones.
-
If your private services use a network address translation (NAT) gateway to reach the public internet or external APIs, add the hourly gateway fee and any per-GB processing charge. Traffic that crosses availability zones can add a transfer charge too.
-
Model a "Baseline" scenario using expected traffic and a "Spike" scenario using an arbitrary 5x traffic multiplier. This shows which charges change with traffic, such as outbound transfer and web compute at peak, and where extra instances may be needed.
Copy this worksheet and fill in the final column. Duplicate the compute row for each web service, worker, database, and queue or cache. Keep quantities and rates in the same billing units:
Charge | Inputs to enter | Calculation | Monthly charge |
|---|---|---|---|
Workspace subscription, if applicable | Current subscription fee | Enter the fee once | Enter amount |
Compute, one row per resource | Instance count, running time, rate per instance per unit of time | Count × time × rate | Enter amount |
Storage, one row per volume | Billable GB-months after included capacity, rate per GB-month | Billable GB-months × rate | Enter amount |
Outbound traffic | Metered outbound GB, shared included GB, rate per GB | max(usage − included amount, 0) × rate | Enter amount |
Builds | Pipeline usage, included amount, purchase rules | Apply the provider’s billed-usage or purchase rules | Enter amount |
Other applicable charges | External services, licenses, support, applicable taxes, and anything else your host bills | Apply each resource’s billing rules | Enter amount |
Monthly total | Completed charge cells | Add the charges above | Enter amount |
For consumption-based compute, enter the provider’s measured billing units, such as CPU, memory, or execution time, in separate rows. Apply a shared workspace allowance once. Check minimum charges, rounding, and purchase increments before totaling. Keep database storage and an attached service disk in separate rows only when your app uses both. Repeat the worksheet with higher traffic, changing only the affected quantities or resource sizes.
Which inputs matter for each workload?
A blank worksheet lists every charge in the same format, so no line looks bigger than another. Which lines move the total depends on the app: a job queue moves the worker lines, a large database moves the database and storage lines, and a busy API moves the outbound transfer and web compute lines. The table below names them, and the sections after it walk through each kind of app on Render. If your app fits multiple rows, keep all of them.
App | Lines that move the bill | Easy mistake |
|---|---|---|
Worker-heavy | Worker size, count, time on, and the queue | Treating workers that are waiting as free |
Database-heavy | Database compute, storage, and any cache | Hiding disk inside the web service's compute |
API-heavy | Outbound transfer, web compute at peak, and a worker a request starts | Sizing the web service from the monthly call count |
A worker-heavy app
Say the jobs sit in a queue, and the workers stay up to take the next one. The time they spend waiting is part of the compute line. On Render, each background worker runs as an always-on instance outside the web request. Count the instance size, how many worker instances stay running, and the total time they remain up, including when the queue is empty. If the queue runs as its own service, give it a row too. If the host bills by usage instead, check what still costs money while a worker waits.
A database-heavy app
Now say the expensive part is the data, not the web service. Picture a product catalog that stores 100 GB and keeps an in-memory cache. On Render, database compute and database storage are separate rows, and any persistent disk attached to the web service is its own storage row. When the web service, cache, and database communicate over internal addresses in the same workspace and region, those queries and cache reads do not add bandwidth charges.
An API-heavy app
Now say the app sends a lot of data to users. Picture 5 million calls a month and 250 GB sent out. The 250 GB is the outbound row. The call count does not tell you the instance size. Size the web service from how long each request runs, how much memory it needs, and the busy hour. If a request starts a background job, that worker and its queue are another compute row. On Render, public outbound traffic past the workspace allowance is the bandwidth line. If that web service can add instances as traffic grows, the minimum count is the compute you pay for when it is quiet, and the maximum count is the ceiling.
Conclusion
Cloud bills rarely surprise teams because a single web server cost more than expected. Surprises happen when an estimate ignores the rest of the production stack: background workers waiting on a queue, database storage growing month over month, traffic spikes forcing extra instances, or NAT gateways adding hidden network fees.
Pricing every service in your stack across both baseline load and a traffic spike turns your cloud bill from a post-launch surprise into an engineering tradeoff you can see upfront. As your traffic grows or you add a worker, database, or cache, update your worksheet so your budget scales with your architecture.
Deploy your web services, background workers, and managed databases on Render to get predictable compute pricing and free private networking in one workspace.