Know your working set.
The size of your database on disk is only one number. Indexes, hot rows, connection pools, sorting and cache can all use memory. Measure the working set and leave space for the operating system and maintenance jobs.
Studio is where we start the conversation.
Studio 16, Studio 32 and Studio 64 provide progressively larger memory allocations. They are sensible configurations to evaluate for multi-service stacks and data-intensive work. They do not automatically make a single-node database highly available.
Separate durability from availability.
A backup helps recover data. A replica can help availability. Neither is a substitute for the other. Write down the amount of data you can afford to lose and how long your service can be unavailable, then design a recovery process around those limits.
Protect the data path.
- Restrict database listeners and firewall rules.
- Use encrypted transport where supported.
- Create application-specific database users with limited privileges.
- Test backups for consistency rather than copying live data files blindly.
- Monitor disk usage, I/O latency, memory pressure and slow queries.
Personal information needs an extra step.
Agree the processing roles, location and data-processing terms before hosting personal information for which we act as a processor. Do not assume that a VPS purchase by itself meets every compliance requirement.
Data processing and your VPS