Beste VPS voor databasehosting: kies de configuratie voor uw werklast

Twee databases kunnen evenveel schijfruimte gebruiken en verschillende VPS-configuraties vereisen. De ene leest steeds weinig rijen; de andere schrijft voortdurend, bouwt grote indexen of moet snel herstellen na uitval. De keuze voor de beste database-VPS begint met deze verschillen, vóór de vergelijking van aanbieders.

Een onbeheerde VPS kopen betekent ook verantwoordelijkheid voor databasebeheer. PostgreSQL, MySQL en MariaDB hebben verschillende geheugenbudgetten; herstelcapaciteit hoort bij het ontwerp van de primaire server. De startconfiguratie moet ruimte laten voor back-ups en onderhoud en een representatieve lasttest doorstaan.

Meet de databasebelasting vóór de pakketkeuze

Meet actieve gegevens en indexen, gelijktijdige query's bij piekbelasting, groei en herstelbehoeften voordat u CPU, RAM of schijf kiest. Voeg middelen toe voor het gemeten knelpunt. Neem onderhoudsruimte en applicatiepieken op bij gedeelde hosting; het budget moet drukte én normaal gebruik aankunnen.

De werkset bevat gegevens en indexen die vaak genoeg worden benaderd om van geheugenresidentie te profiteren. De opgeslagen omvang omvat ook koude gegevens. Open verbindingen zijn geen actieve query's: inactieve clients en gelijktijdige sorteringen vragen andere CPU en RAM. Leg beide vast, inclusief queryvorm en lees-/schrijfverhouding.

Bepaal aankoopvereisten vanuit een representatieve drukke periode:

• Meet het piekgeheugen van de applicatie als deze de VPS deelt.
• Noteer gegevens- en indexomvang, geschatte werkset, gelijktijdige bewerkingen en groei in de geplande capaciteitsperiode.
• Meet logproductie en bepaal de grootste verwachte indexbouw, tabelherschrijving of onderhoudsbewerking.
• Leg p95-latentiedoel, aanvaardbaar gegevensverlies en beoogde hersteltijd vast.
• Bepaal de applicatielocatie en test de verbinding naar de database.

De monitoringdocumentatie van PostgreSQL adviseert databasestatistieken met besturingssysteemtools te combineren. Meet CPU, geheugendruk en schijfactiviteit naast query- en committijden. Onderzoek hogere latentie tijdens back-ups, ook als een onbelaste server goed lijkt.

Dedicated vCPU's bieden voortdurend toegang tot toegewezen CPU-capaciteit. Ze betekenen geen volledige fysieke server of gegarandeerde IOPS. Beoordeel CPU, geheugen en opslaggedrag apart. Overschrijden gemeten eisen de VPS-opties, onderzoek dedicated hardware in plaats van uit de naam van een groter pakket te extrapoleren.

Koppel SQL-belastingen aan een startconfiguratie

Gebruik PostgreSQL 16, MySQL 8.4 met InnoDB of MariaDB 11.4 met InnoDB als alternatieve voorbeelden volgens applicatiecompatibiliteit. De engines zijn niet uitwisselbaar en worden niet als nieuwste versie voorgesteld. Noteer de geïnstalleerde patchversie vóór tests; de voorbeelden bepalen geen imageversie van de aanbieder.

Plaats kleine applicatie en database samen

Test voor aangenomen 3 GB gegevens, 1 GB warme werkset en vijf actieve eenvoudige geïndexeerde query's een VPS met 2 vCPU's, 4 GB RAM en 60 GB nominale SSD of NVMe. De verbinding blijft lokaal, maar app en database moeten samen in het piekgeheugen passen.

Veronderstel 90/10 lezen/schrijven, 1 GB groei per maand en geen lange rapporten tijdens back-ups. Gedeelde CPU kan volstaan voor tolerante staging. Kies dedicated capaciteit als langdurige concurrentie de reactietijden schaadt; de productieplannen hieronder gebruiken uitsluitend dedicated vCPU's.

Voorgestelde RAM-verdeling, alle cijfers in GB:

Pas de InnoDB-pool van MySQL/MariaDB binnen dit budget. Een percentage voor een dedicated databaseserver op de hele host toepassen verbruikt applicatiegeheugen. Reken bij PostgreSQL gedeelde buffers en bewerkingsgeheugen apart binnen databasebudget en reserve. Meet de gezamenlijke piek voordat u een configuratie accepteert.

Schijfvoorbeeld: 5 GB OS/logs, 3 GB gegevens/indexen, 4 GB enginelogs, 3 GB tijdelijk en 6 GB groei, totaal 21 GB. De nominale rest dekt bestandssysteemoverhead en tijdelijk werk; dit rechtvaardigt geen back-upretentie op de primaire server.

Verbind via lokale socket of localhost. Test duurzame commits met actieve app en back-up, inclusief opslagsynchronisatie (fsync), waarmee het OS gegevens naar duurzame opslag schrijft. Accepteert de eigenaar RPO van 24 uur, het verliesvenster, en RTO van vier uur, de hersteltijd, plan dan nachtelijke native back-ups buiten de node en bewijs hersteltijd in een oefening. Bij falend RAM-, latentie- of herstelbudget: splitsen, vergroten of herstel herzien na query-/indexdiagnose.

Plaats transactionele SQL-database apart

Voor een externe app kan een voorbeeld-SQL-database van 12 GB met 6 GB warme werkset starten met tests op 2 dedicated vCPU's, circa 16 GB RAM en 50 GB lokale opslag. Aannames: 20 actieve geïndexeerde query's, korte schrijfacties en weinig langdurige berekening; grotere bewerkingen kunnen het budget ontkrachten.

Veronderstel 90/10 lezen/schrijven en 1 GB maandgroei gedurende drie maanden. Dit is de referentie voor de aanbiedertabel. Eenheden verschillen: vergelijk werkelijk beschikbaar geheugen en bruikbare bestandssysteembytes vóór toewijzing.

Voor PostgreSQL-VPS begint de richtlijn voor gedeelde buffers van PostgreSQL 16 op 25% systeemgeheugen bij een dedicated databasehost met minimaal 1 GB RAM. PostgreSQL gebruikt ook OS-cache. Voorstel 16 GB: 4 GB gedeelde buffers, 2 GB OS/agents, 2 GB query-/verbindings-/onderhoudsreserve en 8 GB bestandscache/speling.

De reserve is geen work_mem-waarde. De documentatie over querygeheugen van PostgreSQL legt uit dat afzonderlijke sorteer- en hashbewerkingen elk geheugen kunnen toewijzen terwijl meerdere sessies lopen. Hashes gebruiken ook hash_mem_multiplier. Begrens per toegestane gelijktijdigheid; hoge waarden per bewerking kunnen het hostbudget overschrijden ondanks voldoende gedeelde buffers.

Voor MySQL-VPS adviseert Oracles MySQL-8.4-bufferpoolrichtlijn doorgaans 50–75% systeem-RAM met ruimte voor OS en andere toewijzingen. Test 8 GB InnoDB en houd de rest voor overige verbruikers en pieken.

MariaDB vraagt een andere berekening. De richtlijn voor geheugenverdeling begint bij overwegend InnoDB op 60–70% RAM beschikbaar na OS/diensten. Bij 13 GB is dat 7,8–9,1 GB; 8 GB startpool past. MyISAM of Aria vragen eigen cacheplanning. De enginebudgetten zijn alternatieven: tel ze niet op.

Schijf: 12 GB gegevens/indexen + 3 GB groei + 5 GB OS + 4 GB logs + 8 GB tijdelijk/onderhoud = 32 GB. Een schijf van circa 50 GB laat 18 GB nominaal vóór overhead. Eis minimaal 15 GB gemeten vrije ruimte; meer logs of grotere herschrijvingen ontkrachten dit voorbeeld.

Plaats app en database dichtbij, met getest privépad indien ondersteund, authenticatie, toegangscontrole en encryptie. Meet query- en duurzame commitlatentie bij checkpoints, flushes en back-ups. Reserveer onafhankelijke back-upopslag; hieronder volgt herstelontwerp. Vergroot bij verzadiging, onvoldoende ruimte of falende hersteldoelen na query-/indexdiagnose.

Budget voor grotere werksets of voortdurende schrijflast

Test bij aangenomen 100 GB data en 16 GB warme set 4 dedicated vCPU's, 32 GB RAM en circa 300 GB NVMe. Houd de app apart. Dit voorbeeld staat 30 actieve gemengde query's en 60/40 lezen/schrijven toe; meet uitvoering en opslagdruk vóór uitbreiding.

Veronderstel 10 GB maandgroei over drie maanden. PostgreSQL: 8 GB gedeelde buffers, 4 GB OS/query/onderhoud en 20 GB bestandscache/speling. Voor MySQL/MariaDB is circa 16 GB InnoDB een alternatief na andere reserves. PostgreSQL-instellingen zijn niet overdraagbaar.

Opslag omvat lopend werk: 100 GB gegevens/indexen + 30 GB groei + 30 GB bewaarde/wachtende logs + 60 GB grootste tijdelijke/onderhoudstaak + 10 GB OS = 230 GB. Ongeveer 70 GB nominaal blijft. Grotere tabelherschrijvingen vragen herberekening, ook bij beperkte dagelijkse groei.

De documentatie over routinematig vacuum van PostgreSQL onderscheidt VACUUM, dat dode-rijruimte herbruikbaar maakt, van VACUUM FULL, dat een nieuwe tabelkopie schrijft en tijdelijk extra ruimte vraagt. Een schijf nauwelijks groter dan de dataset kan noodzakelijk ruimteherstel verhinderen.

Meet CPU, cachedruk en fysieke I/O apart van schrijflatentie. Neem tijdelijke schrijfacties en checkpoint-/flushfasen mee. NVMe en dedicated CPU beschrijven configuratie, geen IOPS-garantie. Test aanhoudende back-up- en replicatietransfers met nabij privépad en onafhankelijke herstelopslag. Snellere logproductie verandert retentie en netwerkbehoefte. Verhoog cores, RAM of schijf volgens de gemeten beperking, niet omdat het volgende pakket alles verhoogt.

Voeg herstelcapaciteit toe aan productie

15 minuten geaccepteerd verlies en één uur herstel vragen meer dan het primaire budget. Behoud de aparte SQL-aannames en voeg native back-ups, bewaarde logs, onafhankelijke opslag en getimede oefening toe. Dit zijn planningsdoelen; alleen de oefening toont haalbaarheid.

De documentatie voor doorlopende archivering van PostgreSQL beschrijft basisback-up en ononderbroken WAL-archief voor tijdstipherstel. Oracles MySQL-hersteldocumentatie gebruikt volledige back-up en binaire logs. MariaDB's PITR-procedure herstelt volledige/incrementele data vóór logreplay. Binaire logging moet aanstaan voor deze MySQL-/MariaDB-routes.

Capaciteitsvoorbeeld: elke ongecomprimeerde volledige/basisback-up is 12 GB. Bewaar drie wekelijkse bases en doorlopende logs vanaf de oudste. Budgetteer maximaal 21 dagen met 2 GB per dag plus 20% marge:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

Plan minimaal 100 GB onafhankelijke back-upopslag zonder compressie aan te nemen. Koppel logverwijdering aan back-upverval en geslaagde vervanging. Controleer een volledige keten voor elk beloofd herstelpunt.

Gebruik back-ups op een onafhankelijk doel met gescheiden accounts en verwijderrechten. Een providersnapshot bewijst de native keten niet. De oefening moet een schoon doel maken, overdragen en herstellen, logs afspelen, database-/appconsistentie controleren en de app routeren. Meet ook provisioning en overdracht.

Kortere uitval kan een onafhankelijke replica voor de volledige last vereisen. Plan CPU, RAM en schijf afzonderlijk, plus promotie, uitschakeling van de oude primaire en clientrouting. Oefen de volgorde. Replicatie vervangt geen back-ups en één VPS is geen hoge beschikbaarheid. Herzie bij herstel boven één uur, archiefvertraging boven RPO, ongeschikte standby of bijna volle back-upopslag.

Wanneer een beheerde VPS kiezen

Kan niemand reageren op alarmen of herstellen bij incidenten, koop dan expliciete operationele dekking. Een beheerde VPS kan onderhoud overnemen, maar het contract moet databasetaken noemen. Een paneel bewijst geen dekking; beheerde VPS en beheerde database verschillen.

Het verschil tussen verantwoordelijkheden van beheerde en onbeheerde VPS helpt per taak. Dit is een inkoopchecklist, geen belofte van gelijke diensten. Fysieke infrastructuur blijft bij de aanbieder; gastsoftware en databaseoperaties vereisen expliciete eigenaren.

Nuttige contractvraag: ‘Als de schijf tijdens back-up volloopt, wie diagnosticeert, herstelt en controleert de volgende back-up?’ Dit scheidt supporttoegang van resultaatverantwoordelijkheid. Vraag ook naar mislukte upgrades en onbedoelde verwijdering.

Beheerde databases hebben eigen afspraken voor enginelevenscyclus, back-ups en failover. Ze passen beter als u herstel en upgrades wilt overdragen. Leid daaruit geen appoptimalisatie af; queryontwerp en appgedrag houden een eigenaar nodig tenzij anders overeengekomen.

Wijs elke taak eenmaal toe, met escalatie en acceptatiecheck. Vergelijk kosten met uw tijd en beschikbaarheid. Zelfbeheer kent geen universele uurwaarde; goedkope rekenkracht verhelpt geen incident zonder eigenaar.

VPS kiezen voor niet-SQL-werklasten

De voorbeelden onderscheiden geheugen, documenten en zoekindexering. Plaats de app dichtbij en test verbindingen plus transfers naar back-ups en eventuele replica's.

Redis' beheeradvies waarschuwt dat schrijfintensieve RDB-opslag of AOF-herschrijving afhankelijk van gewijzigde pagina's tweemaal normaal RAM kan gebruiken. De 2 GB dataset mag dus niet alle RAM bezetten. De persistentiedocumentatie onderscheidt periodieke RDB-snapshots en AOF-log. Kies op geaccepteerd verlies en meet RAM-/schijfpieken tijdens uitvoering.

MongoDB's WiredTiger-cachedocumentatie beschrijft interne en bestandscaches. De standaard interne cache is de grootste van 50% × (RAM − 1 GB) en 0,256 GB. Het replica-setadvies beveelt drie datahoudende leden aan. Een arbiter stemt maar bewaart geen data. Plan onafhankelijke back-ups en configureer MongoDB-authenticatie vóór de appverbinding.

Elastics JVM-instellingsdocumentatie adviseert automatische heapdimensionering. Handmatig: gelijke minima/maxima en hoogstens 50% beschikbaar RAM. Het advies voor kleine-clusterweerbaarheid beschrijft twee datahoudende, mastergeschikte nodes plus een alleen-stemmende beslisser. Configureer replica's en routeer clients naar datanodes; de beslisser voegt een stem toe, geen kopie. Herzie schijfbudget bij volle merge-/retentiereserve vóór meer documenten.

Vergelijk onbeheerde pakketten voor uw configuratie

Filter de aparte transactionele SQL-last op minimaal 2 dedicated vCPU's, circa 16 GB RAM en 50 GB lokaal. Slagen maakt een pakket testkandidaat. Verschillende CPU-/schijfbundels, eenheden en facturering verhinderen hardwaregelijkheid of prestatievolgorde.

Referentie: zelfbeheerd Linux in Duitsland of nabij Midden-Europa, weinig data met meer RAM. Nabijheid garandeert geen gelijke latentie. Privépad waar ondersteund; offertes behouden standaard publieke IPv4. Veronderstel transfers onder alle limieten.

DigitalOceans keuzedocumentatie noemt Memory-Optimized voor SQL/NoSQL en caches. Ik adviseer deze bundel voor weinig schijf en veel RAM. Geheugenoptimalisatie betekent geen SQL-exclusiviteit. Meet u opslagcapaciteit of langdurige opslagvraag als knelpunt, beoordeel Storage-Optimized apart.

Alle vijf voldoen aan de ondergrens met verschillende CPU-/schijfreserves. Die kunnen groei opvangen, maar bewijzen zonder test geen databasevoorsprong. Hetzners vermelding garandeert geen bestelvoorraad. Akamai documenteert SSD voor G7 Dedicated. Vultrs Optimized Memory staat los van gedeeld High Frequency Compute.

Onze dedicated toewijzing past bij de zelfbeheerde configuratie tegen de getoonde prijs. Vergelijk middelen, valuta, factureringsverplichtingen en IPv4-kosten vóór het totaaloordeel.

Eigendomskosten: rekenen + adres + onafhankelijke back-upopslag/verzoeken/transfer + hersteltestcapaciteit + optionele standby. Onbekende kosten zijn niet nul. Vraag actuele herstelprijzen en verifieer pakket, locatie en upgradepad vóór binding. Leid geen jaarfactuur af uit een afgerond maandequivalent.

Na keuze van compatibele SQL-engine verkorten onze éénklikapps de installatie. PostgreSQL, MySQL en MariaDB zijn aparte keuzes; één installeert niet alle drie. Patches, tuning en herstel blijven zelfbeheer.

Veelgestelde vragen

Toont PostgreSQL's cachetrefferpercentage trage opslag?

Nee. De I/O-statistiekdocumentatie van PostgreSQL verklaart dat OS-cache een leesactie zonder schijf kan afhandelen. Combineer treffers met OS-I/O en querytijden. De verhouding alleen onderscheidt fysieke vertraging niet van lezen uit kernelgeheugen.

Kan een logische PostgreSQL-dump WAL-tijdstipherstel ondersteunen?

Nee. De vereisten voor doorlopende archivering van PostgreSQL zeggen dat logische dumps informatie voor WAL-replay missen. Een dump herstelt de vastgelegde toestand; WAL-herstel vereist een geschikte basisback-up en doorlopend WAL-archief. Kies formaat volgens herstelmethode.

Moet MongoDB-cache in een container het host-RAM gebruiken?

Gebruik het voor de container beschikbare geheugen. MongoDB's advies over containergeheugen waarschuwt dat WiredTiger een lagere containerlimiet soms mist. Stel cache daaronder met ruimte voor andere processen; host-RAM kan beschikbaar databasegeheugen overschatten.