Dedicated vs Shared Postgres Hosting: When to Upgrade

On shared Postgres hosting, your database runs on a server alongside other customers' databases, sharing CPU, memory and disk. On a dedicated Postgres server, the machine runs only your databases. Shared hosting is cheaper and fine for most apps early on; a dedicated server makes sense when you need predictable performance, more memory than a shared plan offers, higher connection limits or a large database, and the bill for it is smaller than the cost of slow pages or engineering time spent working around limits.

This article explains how the two models work, what actually differs in practice, and the signals that it is time to upgrade.

#How shared hosting works

There are a few flavors of "shared":

• Shared server, separate databases. Each customer gets their own Postgres database (or cluster) on a server that hosts many. Isolation is at the database and role level; resources are shared.
• Shared server, separate containers or VMs with resource limits per tenant. Better isolation, more overhead.
• Serverless or disaggregated storage, where compute and storage are separated and compute scales per workload.

The economics are the same: the provider spreads the cost of a big machine across many small workloads, most of which are idle most of the time.

On StitchDB's shared servers, every project has its own Postgres database with its own roles, password, JWT secret and API keys. Only your project's roles can connect to your database, and other projects on the same server cannot see or reach it. See Security.

#How a dedicated Postgres server works

A dedicated server runs only your workloads. All of its CPU cores, memory and disk I/O are yours. You choose the size, and you pay for it whether it is busy or idle.

"Dedicated" can mean a dedicated VM on shared hardware (vCPUs that are slices of a bigger host) or a whole physical machine with dedicated cores. Ask which one you are getting.

#What actually differs

#Noisy neighbors

The biggest practical risk on shared hosting is another tenant's workload. A neighbor running a heavy batch job can raise disk latency or CPU contention for everyone on the box. Good providers limit this with per-project limits (requests per second, connections, statement timeouts), but they cannot remove it entirely.

On a dedicated server, the only noisy neighbor is you.

#Memory

Postgres performance depends heavily on whether your working set fits in memory. If your hot tables and indexes fit in the page cache and shared_buffers, most reads never touch disk. When they no longer fit, latency jumps. Dedicated servers let you buy memory directly.

-- cache hit ratio for table reads; well below 99% on a busy OLTP app suggests memory pressure
select round(100.0 * sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0), 2) as hit_pct
from pg_statio_user_tables;

#Signs it is time to go dedicated

• Latency varies at times that do not match your traffic. Slow periods you cannot explain from your own load suggest contention.
• Your working set no longer fits in memory. Cache hit ratio drops, disk reads climb.
• You hit connection limits even with pooling in place.
• Your database is heading into hundreds of GB. Large tables need fast disk and room for maintenance.
• A customer contract requires it. Some enterprise buyers want dedicated infrastructure.
• CPU-heavy queries (analytics, search, vector similarity) compete with your app traffic.

#Things to try first

Before you pay for a bigger box, make sure the problem is capacity and not something cheaper:

1. Fix the slow queries. Check pg_stat_statements; add indexes for the top offenders.
2. Pool connections. Many "too many connections" problems disappear with transaction-mode pooling. See Postgres Connection Pooling Explained.
3. Move reads off the primary. Read replicas take dashboards and reports elsewhere.
4. Partition huge append-only tables. Events and logs partitioned by time keep indexes small.
5. Archive old data. Smaller tables cache better.

#The cost math

Compare the dedicated server's monthly price against:

• The engineering time you spend on workarounds each month.
• Revenue or conversion lost to slow pages, if you can estimate it.
• The cost of read replicas and caching layers you would otherwise add.

A dedicated server is often cheaper than it looks once you count those, and more expensive than it looks if your real problem was one missing index.

#Dedicated servers on StitchDB

On the Scale and Enterprise plans, StitchDB projects can run on a dedicated server that hosts only them, in StitchDB's European data centers (Falkenstein and Nuremberg in Germany, Helsinki in Finland). The details, from the Compute docs:

Sizes. From Small (4 GB RAM) through Medium, Large, XL, 2XL, 4XL and 8XL (192 GB) to 16XL (384 GB or more). Each size shows its memory, whether cores are shared vCPU or dedicated, NVMe disk, and the connection limits per project, which grow with the size and are never lower than the plan's. Live prices for the sizes available right now are on the pricing page and in Settings › Compute.

Choosing. Move a size slider and see the price, memory, CPU, disk and connection limits update. Choose whether it applies to one project or every project of the account. Before you confirm, you see the monthly price, the average hourly price, the amount for the rest of this month and whether your prepaid credit covers it.

Moving. Your projects move online, with a write pause of about a second. Project URL, API keys and connection strings never change, before, during or after the move. The first dedicated server of an account, and every monthly-billed size, is approved by the StitchDB team, usually within a business day.

Billing. Most sizes are billed hourly from prepaid credit (the hourly price is the monthly price divided by 730), the largest monthly in advance. If setup fails, nothing is charged. If credit runs out, you are e-mailed, and after a grace period projects move back to shared servers with no downtime, so you never build up debt.

Large storage. For very large databases, choose Large storage, enter the size you need, and see only servers with at least 1.5 times that much usable disk: large local NVMe, or attached network storage up to 10 TB (slower than local NVMe). See Large databases.

Resize or stop. Resizing creates a server of the new size, moves your projects with no downtime and deletes the old one. Stopping moves projects back to shared servers.

What does not change. Plan limits such as database size, file storage and requests per second still apply on a dedicated server. The server gives you your own CPU, memory, disk and higher connection limits, not unlimited quotas.

Your own servers. Accounts enabled by the StitchDB team can also run projects on servers they own (a fresh Ubuntu or Debian server with a public IPv4 address), managed by StitchDB. Projects on your own servers have no compute charge and do not count toward the plan's project limit, but usage is billed as usual.

#Trade-offs to weigh

• Dedicated is per-month spend that does not shrink at night. If your traffic is spiky and mostly idle, shared hosting or a serverless database may be cheaper.
• On StitchDB, dedicated servers are EU-only, like the rest of the platform.
• Bigger is not always faster. A single-threaded slow query is just as slow on 32 cores as on 4. Fix queries first.

#FAQ

#Is shared Postgres hosting secure?

It can be. What matters is isolation: separate databases and roles per tenant, no cross-database access, blocked extensions that could cross boundaries, and TLS. Check the provider's security docs.

#Will my connection string change when I move to a dedicated server?

On StitchDB, no. URL, keys and connection strings stay the same.

#How long does a move take?

On StitchDB, the move runs online with a write pause of about a second. Setting up the server takes minutes for most sizes, a few hours for the largest.

#Can I go back to shared?

Yes. Stopping the dedicated server moves your projects back to shared servers without downtime.

See dedicated server sizes and live prices on the pricing page, or read why StitchDB.