Database Hosting
Keep the Database Beside the App and Off the Public Internet.
Has your Postgres outgrown shared hosting? The simplest solid setup is the app and database on one VPS, with the listener on loopback. Splitting them means securing that connection yourself, because Riven Cloud has no private networking product.
Nothing on the Internet should be able to reach your database directly. Loopback gives you that for free; a split setup makes it your engineering problem.
One Box or Two
Start with Everything on One Box
For most apps that outgrew shared hosting, one VPS running both the app and the database is the right answer. The listener sits on loopback and never faces the Internet. Want the database elsewhere? Securing that path becomes your job; we have no private networking product.
App and Database on One Box
They talk over a local socket, the listener never faces the Internet, and there is only one server to look after.
A Split You Secure Yourself
A separate database VPS can work, but only if you restrict it to known application addresses and own every control on that path.
Someone Who Knows the Engine
Postgres and MySQL reward an operator who patches, tunes, and above all practices restores.
Who Reaches It
Only the App Talks to the Database
The application faces the public. The database faces the application, and nobody else. Administration takes its own controlled path.
- 01
The Public Face
The app takes the requests, validates input, and connects to the database with an account scoped to what it actually needs.
- 02
The Listener
Loopback when everything shares a host. On a separate VPS, allow only known application addresses and secure the path yourself; there is no private network product to lean on.
- 03
The Admin Path
psql over SSH, not a management port on the Internet. Log the privileged changes while you are at it.
What We Supply
Your Engine, Your Config, Our Hardware
We supply the Linux server and the NVMe underneath. The engine choice, memory tuning, listener rules, and anything connecting two systems are yours to configure.
- Configure the engine properlyFull root access
- Install Postgres or MySQL from the distribution, then set the memory, logging, and listener rules the way the engine docs recommend.
- Size by the working setPremium, Ultra, Max plans with current vCPU, RAM, NVMe, and monthly transfer limits
- Active data, write volume, and maintenance headroom decide the plan. The engine name decides nothing.
- Layer backups correctlyDaily backups
- Our daily backups sit underneath as infrastructure. A consistent recovery point still needs pg_dump, WAL archiving, or your engine's equivalent.
Placement
Place the Database with Its Application
Same location as the app, always, unless you have designed and tested the split. Measure user latency through the application; never open a database port just to test it.
Current mainland-China paths: China Telecom: CTGNet (formerly China Telecom CN2 GIA, AS23764 / AS4809); China Unicom: CUP (China Unicom Premium, AS9929 / AS10099); China Mobile: CMIN2 (China Mobile International N2, AS58807).
- 01Keep app and database together unless you have tested the separate connection and its failure behavior.
- 02Test Tokyo and Singapore from your users' networks, through the public application.
- 03Measure query time at the application, pool waits included. A ping is not a database benchmark.
Looking Glass output is a snapshot of the path at the moment you ran the test; day-to-day latency and app performance can differ. Read the network and locations pages for route terminology and facility context.
Working Set
Size by the Working Set, Not the Engine Name
The question is how much of your data is hot at once. Compare that, plus writes and growth, with the RAM and NVMe on each plan.
The Slow Queries
Log them and look. A missing index costs more than a plan upgrade, and no hardware hides a table scan forever.
Does the Hot Data Fit in RAM
When the working set outgrows memory, reads hit disk and everything slows at once. Watch cache hit rates and swap.
Space for the Boring Stuff
WAL, dumps, and reindexing all want disk. Upgrades want the most, right when you have the least.
Premium
- 2 vCPU (AMD Ryzen 9950X)
- 4 GB RAM
- 40 GB NVMe
- 1 TB/mo transfer
Ultra
- 2 vCPU (AMD Ryzen 9950X)
- 8 GB RAM
- 80 GB NVMe
- 2 TB/mo transfer
Max
- 4 vCPU (AMD Ryzen 9950X)
- 16 GB RAM
- 160 GB NVMe
- 4 TB/mo transfer
Failure and Restores
One Server Is One Failure Domain
A single VPS does not replicate itself or fail over. If the database must survive a host failure, you are building and testing that architecture on top.
Riven Cloud supplies an unmanaged Linux KVM VPS with full root access. Everything inside it, from the firewall to the backups, is yours to operate.
- Never expose a database or admin port to the public Internet. There is no good reason, and there are many bad outcomes.
- Any separate database connection is yours to design and run; Riven Cloud has no private networking product.
- Provider backups alone will not give you a consistent recovery point. Use pg_dump, WAL archiving, or your engine's method, and prove the restore before you need it.
Further reading
Worked Examples with Real Restores
Questions
Database Hosting FAQ
Can I expose a database port to the Internet?+
Please do not. Keep the listener on loopback or a restricted interface, allow only known application paths, and reach the admin side over SSH. Scanners find open database ports quickly.
Are daily provider backups enough for a database?+
No. They are a safety net under whatever you build, not a consistent restore point. Use pg_dump, WAL archiving, or your engine's equivalent, keep a copy off the server, and actually test a restore.
Settled on One Box, Listener on Loopback?
Then compare your working set, write volume, and growth against the RAM and NVMe on the current plans.