How much RAM does a self-hosted database need?

For one app — a Postgres or Redis instance plus its backend — 1.7-2 GB is a realistic working set, so Small ($8) fits. Several apps, or a production database with real concurrency, push you to Medium ($12), and if other machines need to reach it, a dedicated-IP plan. Size it by working set and connection count, not by hope.

Why self-host instead of a managed database?

Control. You get the whole postgresql.conf, superuser, and any extension you want — pgvector, PostGIS, TimescaleDB, pg_cron — things managed tiers often lock down or charge extra for. The trade-off is that backups, tuning, and upgrades are yours to run. If you want to own the box, this is the point.

Is a shared VPS fine for a production database?

For a small-to-moderate app, yes. For heavy OLTP — hundreds of transactions a second, latency-critical writes — a shared-vCPU box is the wrong tool, and we'll say so rather than sell you one. Disk I/O and a guaranteed clock matter there, and shared plans don't promise either.

How do I let my other servers connect to the database?

Bind Postgres to the right interface, open the port only to the IPs that need it, and use a plan with a dedicated IPv4 so the address is stable and reachable. Never expose 5432 to the whole internet — firewall it to your app servers and require TLS.

Do I need to give you an ID?

No. Email to sign up, USDC or USDT to pay. No documents, root in about a minute.

VPS for a Database

Self-host PostgreSQL or Redis on a VPS with full root — the whole postgresql.conf, extensions a managed service won't let you install, and honest limits on what a shared box can and can't take. From $8/mo.

There's a specific moment where a managed database stops being convenient and starts being a wall. You want an extension the tier doesn't offer. You want to see the actual query plan and tune work_mem. You want a superuser. A managed service is a great default right up until you need to own the thing — and then a VPS with full root is the honest answer.

This page is about running your own PostgreSQL or Redis correctly, and being clear about where a shared box is the right call and where it isn't.

What a database actually needs

Databases care about two things a game server doesn't: memory for the working set and disk I/O. The rough shape:

One app — a Postgres (or Redis) instance plus a backend service. The working set is usually 1.7-2 GB. Small ($8) handles it without drama.
A few apps, or real production concurrency — more connections, bigger caches, background jobs. Medium ($12) gives you the headroom.
Other machines need to reach it — you want a stable, routable address, so a dedicated-IPv4 plan (Small-IP $16 and up). More on that below.

Redis is lighter still — it's memory-bound, so size the plan to your dataset plus overhead and you're done. Postgres is the one that rewards a little tuning.

The real reason to self-host: control

This is where a VPS earns its place. On your own box you get:

The whole postgresql.conf — shared_buffers, work_mem, max_connections, WAL settings, all of it, tuned to your workload instead of a vendor's defaults.
Any extension. pgvector for embeddings and semantic search, PostGIS for geospatial, TimescaleDB for time series, pg_cron, pg_stat_statements — install what you need. Managed tiers frequently restrict the extension list or gate it behind a higher plan.
Superuser and the OS underneath it. You can move the data directory, tune the kernel, run pg_dump on your own schedule, and set up streaming replication to another box if you want it.

If none of that matters to you, a managed database is genuinely fine and you should use one. This page is for the case where it does.

Where a shared box is the wrong tool

Being straight about it: a shared-vCPU VPS is not built for heavy OLTP — hundreds of transactions a second with latency-critical writes. That workload lives or dies on guaranteed disk I/O and a steady clock, and shared plans promise neither. If that's you, you want dedicated hardware, and we'd rather tell you now than watch your p99 latency embarrass both of us.

For the far more common case — a database behind one app, an internal tool, an analytics store, a cache — a shared plan is exactly right.

Backups are not optional

Self-hosting means backups are your job, and the one rule is: do them before you need them. For Postgres, pg_dump on a cron for logical backups, or WAL archiving for point-in-time recovery on anything you actually care about. Ship the dumps off the box — to object storage or another server — so a dead disk doesn't take the backups with it. Test a restore at least once. A backup you've never restored is a hope, not a backup.

Letting other servers connect

If the database only serves an app on the same box, bind it to localhost and you're done — nothing to expose. The moment another machine needs in, two things change:

You need a stable, routable address — that's a dedicated-IPv4 plan (Small-IP $16, Medium-IP $20). NAT plans share an address, which is fine for outbound but not for being a database other servers dial into.
You firewall it hard. Open 5432 (or 6379) only to the specific IPs that need it, never to 0.0.0.0/0, and require TLS. An open Postgres port on the public internet gets found in minutes.

Picking the plan

Setup	Plan
DB behind one app, localhost only	Small ($8)
A few apps / production concurrency	Medium ($12)
Other servers must connect in	Small-IP ($16) / Medium-IP ($20)
Heavy OLTP, hundreds of TPS	dedicated hardware, not a shared VPS

Most self-hosted databases start on Small and grow into Medium or a dedicated-IP plan as they take on more apps or external clients.

Why here

Full root means it's your database, all the way down — every config line, every extension, your own backup schedule, no tier deciding what you're allowed to install. Payment is crypto (USDC or USDT on Base, Ethereum, or Polygon), no KYC, no documents. Root in about 60 seconds after payment, and you can have Postgres accepting connections a few minutes later.

The honest recap: self-host when you want control — extensions, tuning, superuser — and when your workload is moderate. For a small-to-medium app's database, a shared plan is the right tool. For hundreds of TPS of latency-critical OLTP, it isn't, and we'll say so. Ready? Pick a plan.