Vloxt
Sign inView servers

Use case · Self-managed databases

Match CPU and memory to the workload instead of choosing by label alone.

Dedicated General Purpose, Memory Optimized, or Storage Optimized.

Compare suitable servers

When does a database need dedicated compute?

A small or lightly used database can run on Shared CPU, but sustained transactional work benefits from Dedicated CPU and deliberate memory sizing. The best choice depends on working-set size, write volume, storage behavior, and the latency between the database and its applications.

What the server can support

  • Keep compute allocation predictable
  • Place data near application servers
  • Use server-level backups as one layer of recovery

Decide before deployment

  • Memory working set and connection count
  • Write rate and storage needs
  • Database-native backup and restore testing

Representative architecture

Keep each dependency visible.

This sequence is a planning model, not a prescribed topology. Change it when the application’s measured request and data paths require a different boundary.

  1. 01Application services
  2. 02Database server
  3. 03Database-native backup
  4. 04Independent recovery destination
UsersRequest
Latency-sensitive
ApplicationCompute
Frequent round trips
DatabaseData
Independent copy
RecoveryRestore
Place the most conversational systems close together. Keep a recovery copy reachable through an independent access path.

Selection criteria

  • Measure the active working set and connection count
  • Characterize reads, writes, checkpoints, and storage growth
  • Keep chatty applications close to the database

Failure modes to test

  • Memory pressure turns reads into storage work
  • Storage latency can dominate write-heavy transactions
  • A crash-consistent server copy may not satisfy database recovery needs

Catalogue connection unavailable

No configuration is being guessed.

Current active configurations could not be verified. Use the decision criteria on this page, then retry the catalogue when the connection recovers.

Retry matching catalogue

Recovery implication

Decide what must return before choosing how to protect it.

Combine database-native, consistency-aware backups with an independent copy and a tested restore. Define acceptable data loss and recovery time before setting frequency and retention.

01 · DefineRequired data

Application, configuration, credentials, and database.

02 · ProtectIndependent copies

Server-level and application-aware recovery inputs.

03 · RestoreIsolated target

Recover without overwriting the source by default.

04 · VerifyWorking service

Check data, dependencies, access, and application behavior.

A completed backup job proves that a copy was written. A recovery drill proves that the service can return.

Pre-deployment checklist

  1. Record recovery point and time objectives
  2. Test connection and transaction load
  3. Monitor memory, storage latency, and growth
  4. Perform a database restore drill

Choose from evidence, then observe

The suggested family is a starting point, not a guarantee of application performance. Test the software with representative traffic, monitor the constrained resources, and keep application-aware backups. Vloxt exposes eligible server controls and current catalogue choices; the application architecture remains yours.

Read the complete server-selection guide or explore platform features.