Linisin
Linisin ang mga nilalaman ng database na hindi na kailangan, upang lumiit ang working set at bumalik sa data na talagang inihahatid ng iyong site.
Pagpapanatili ng database
Ang bawat WordPress database ay bumibigat habang tumatagal. Itinuturing ito ng Zinn Digital® bilang isang problema sa engineering, hindi bilang isang support ticket: ang paglilinis, pag-optimize, at pag-aayos ay tumatakbo bilang isang naka-automate na workflow na binibili mo sa isang click — at inaalok ito sa iyo ng platform sa sandaling makita nitong lumalaki ang database. Availability: ang backup at restore sa pamamagitan ng MCP at per-site database throttling ay kasalukuyang ginagawa pa lamang at hindi pa magagamit. Ang lahat ng iba pang inilarawan dito ay live na ngayon.
Ang mga file ng isang WordPress site ay nananatili sa halos parehong laki kung kailan mo ito ginawa. Ang database nito ay hindi. Nagtitipon ang mga table, nawawala sa ayos ang mga index, nag-iiwan ang mga storage engine ng espasyong inilaan na hindi na ginagamit ng anuman, at paminsan-minsan ay napupunta ang isang table sa estadong kailangan itong ayusin sa halip na i-tune. Walang anuman dito ang nag-aabiso. Bumabagal lamang ang site, mas nagtatagal ang mga query, at ang unang napapansin ng sinuman ay ang page na dati ay mabilis pero ngayon ay hindi na.
Sa iisang site lamang, isa itong abala. Sa isang portfolio o network ng daan-daang site, isa itong lumalalang pasanin — ang bawat isa ay mas mabigat nang kaunti kaysa sa kinakailangan, at ang bawat isa ay humihingi sa database server nang higit kaysa sa nararapat.
Ipinoproseso ito ng Zinn Digital® sa parehong paraan ng paghawak namin sa natitirang bahagi ng platform: bilang awtomatiko at nauulit na operasyon. Ang pagpapanatili ng database ay isang first-party na serbisyo na binibili mo mula sa dashboard, at ang pagbili nito ay nagpapatakbo kaagad sa trabaho ng pag-optimize. Walang pila na sasalihan at walang inhinyero na aabangan.
Paglilinis, pag-optimize, pag-aayos, at pag-uulat sa database ng MariaDB ng site, na pinapatakbo bilang iisang trabaho.
Linisin ang mga nilalaman ng database na hindi na kailangan, upang lumiit ang working set at bumalik sa data na talagang inihahatid ng iyong site.
Bawiin ang nakalaan ngunit hindi nagamit na espasyo ng talahanayan at isaayos muli ang mga index at istatistika ayon sa inaasahan ng query planner, upang huminto ang mga pagbasa sa paggawa ng mas maraming trabaho kaysa sa kinakailangan.
Tuklasin at ayusin ang mga talahanayan na nasa masamang estado — ang uri ng pagkabigo na nagiging sanhi upang ang isang mabagal na site ay masira kung pababayaan lang.
Ang pagbili ay sinisingil sa pamamagitan ng billing o iyong wallet, tinutupad, inaabisuhan ka, at minamarkahan ang sarili bilang kumpleto. Kung may maging mali, ang mga refund at dispute ay dumadaan sa parehong landas ng billing tulad ng lahat ng iba pang binibili mo sa amin.
Ang mga serbisyo ng unang partido sa platapormang ito ay may dalawang anyo. Ang ilan ay tinutupad ng kawani: ang pagbili sa mga ito ay lumilikha ng isang gawain sa ating admin queue, na dinidirekta sa tamang departamento, sinusubaybayan at ina-update. Ang pagpapanatili ng database ay hindi isa sa mga iyon. Ito ay awtomatiko — ang pagbili ay nag-a-activate ng isang Temporal workflow na direktang nagpapatakbo ng trabaho sa pag-optimize laban sa iyong site. Instant, walang kahirap-hirap.
Mas mahalaga iyon kaysa sa tunog nito. Ang mga Temporal workflow ay matatag, pwedeng ulitin, at idempotent ayon sa disenyo, na siyang pamantayang sinusunod ng bawat matagalang operasyon sa platform na ito. Kung mabigo ang isang hakbang sa gitna, uulitin ng workflow mula sa kung saan ito tumigil sa halip na kalahating tapusin at iwanan ang iyong database sa isang hindi malinaw na estado. Kung ang isang retry ay magpapatakbo ulit ng operasyon na matagumpay na, ligtas iyon ayon sa konstruksyon.
Ibig sabihin din nito na hindi bumababa ang kalidad ng serbisyo kapag mabigat ang load. Ang sampung customer na sabay-sabay bumili ng pagpapanatili ng database ay hindi nakapila sa likod ng isa't isa para maghintay sa iisang engineer — sila ay sampung pagpapatupad ng workflow, at ang platform ay binuo upang i-scale ang mga ito nang pahalang.
Binabantayan na ng platform ang iyong mga site. Ginagamit nito ang nakikita nito para mag-alok ng tamang serbisyo sa tamang oras.
Mayroong dedikadong seksyon ng Extras sa dashboard kung saan maaari kang mag-browse at bumili ng mga unang-partidong serbisyo kailan mo gusto. Ngunit ang mas kapaki-pakinabang na landas ay ang naghahanap sa iyo: ang mga kontekstwal na upsell. Ang pagpapanatili ng database ay inilalahad laban sa isang lumaking database, ang pag-optimize ng bilis laban sa isang mabagal na site na nabibigo sa Core Web Vitals, ang paglilinis ng malware laban sa isang na-flag na site, at ang migrasyon sa pag-sign up.
Ang mga prompt na ito ay pinapagana ng mga totoong signal ng observability — ang parehong mga sukatan sa bawat site at telemetry ng mapagkukunan na kinokolekta ng platform para patakbuhin ang fleet, hindi isang pangkalahatang buwanang paalala. At ang AI assistant ay maaaring parehong mag-mungkahi ng serbisyo at simulan ito para sa iyo, kaya ang agwat sa pagitan ng pagpansin ng problema at pag-aayos nito ay isang usapan sa halip na isang proyekto.
Ang Maintenance ay ang automated na layer sa itaas. Sa ilalim, ang bawat site ay may kasamang buong kontrol sa database.
Ang bawat site ay nakakakuha ng sarili nitong database, na may suporta para sa maraming database at maraming gumagamit ng database kung kinakailangan ng proyekto.
Pareho silang nakapaloob sa dashboard at naka-single-sign-on — walang hiwalay na mga kredensyal na kailangang pamahalaan, walang hiwalay na pag-login na dapat protektahan.
I-on ang panlabas na access sa database kapag kailangan ito ng isang tool o developer, at i-off ulit kapag hindi na. Ang nakasara bilang default ang makatwirang estado.
I-offload ang mga paulit-ulit na basa sa Redis para mas kaunting mga query na lang ang sinasagot ng database sa simula pa lang. Pag-iwas kasama ang lunas.
Ang kalahati ng performance ng database sa shared infrastructure ay ang bahaging hindi mo kontrolado: kung ano ang ginagawa ng mga site ng ibang tao sa parehong server. Ang aming worker fleet ay nagpapatakbo ng MariaDB na may CloudLinux MySQL Governor, na nagpapatigil o naglilimita sa paggamit ng database bawat site. Ang isang site na nagpapatakbo ng mabibigat na query ay nalilimitahan sa loob ng sarili nitong mga hangganan sa halip na pabagalin ang server para sa mga katabi nito.
Kasama ito sa iba pang bahagi ng isolation stack — mga LVE cap sa CPU, RAM, IO, IOPS, at mga proseso, at ang CageFS na nagbibigay sa bawat tenant ng nakahiwalay na view ng filesystem. Ang layunin ng disenyo sa kabuuan ay pareho: ang isang problema sa isang site ay nananatili sa site na iyon.
Kaya kapag mabagal ang iyong database, ang sagot ay isang bagay na talagang maaari mong pagvohan. Database mo ito, at ang pagpapanatili ng database ang pindutan na nag-aayos nito.
Bahagi ang mga operasyon sa database ng katalogo ng MCP tool, kaya maaaring patakbuhin ang mga ito ng anumang agent na may kakayahang MCP para sa iyo.
Ang aming naka-host na MCP server ay naglalantad ng platform sa Claude Code, Cursor, ChatGPT, Claude Desktop at anumang iba pang ahenteng may kakayahang MCP — isang koneksyon sa halip na hiwalay na integrasyon bawat tool. Ang mga tool sa database sa katalogo na iyon ay may kasamang guarded query, optimise, at backup and restore. Ang pagbili ng Extras ay inilalantad din, sa likod ng isang tahasang hakbang ng kumpirmasyon.
Ang lahat ng magagawa ng ahente ay nakapaloob sa pagkakakilanlan kung saan ito nakakonekta. Ang mga token ay inisyu sa pamamagitan ng OAuth 2.1, na nakatutok sa iyong organisasyon at sa iyong mga pahintulot sa RBAC, bawat tool, at maaaring bawiin. Ang mga mapanirang aksyon ay nangangailangan ng tahasang kumpirmasyon, nalalapat ang mga limitasyon sa paggastos sa mga bayad na aksyon na na-trigger ng AI, at ang bawat aksyon sa MCP ay isinusulat sa audit log kasama ang pagkakakilanlan, tool, mga argumento, at resulta.
Sa pagsasagawa: napansin ng iyong agent na mabigat ang database, nagtanong ito kung dapat ba itong magpatakbo ng maintenance, kinumpirma mo, at tumakbo ang workflow. Ang AI ay isang driver, hindi isang operator na walang nag-aabang.
Ang mga first-party service ay data sa platform na ito, hindi mga naka-hardcode na feature.
A one-off job per site, run automatically once you buy it.
₱1,816.99one-off
It runs within 1 day of purchase, and a full backup is taken before anything is changed. Add-ons are bought per site from your dashboard and appear on your normal invoice — no separate account, no second bill and no minimum term. Prices exclude tax, which is worked out from your billing country at checkout.
Sa karamihan ng mga kaso ay hindi mo na kailangang alamin ito nang mag-isa. Sinusubaybayan ng platform ang paggamit ng mapagkukunan sa bawat site at nagpapakita ng pagpapanatili ng database bilang kontekstwal na alok kapag nakita nitong namamaga ang isang database, at maaaring i-flag ito ng AI assistant at simulan ang gawain para sa iyo. Maaari mo rin itong i-browse at bilhin anumang oras mula sa seksyong Extras ng dashboard, at suriin ang mismong database sa pamamagitan ng naka-embed na phpMyAdmin o Adminer.
Pinapaliit namin ang pangangetMinutes sa halip na balewalain ito. Tumatakbo ang trabaho bilang isang Temporal workflow — matatag, pwedeng ulitin at idempotent — kaya ang nabigong hakbang ay umuulit sa halip na mag-iwan ng kalahating nagawang gawain, at ang paulit-ulit na operasyon ay ligtas ayon sa disenyo. Ang bawat pagtakbo ay naitatala sa kasaysayan ng workflow. Sa mga plan ng Footprint-Free, ang mga pang-araw-araw na backup ay nananatili sa loob ng 30 araw na may pag-restore sa isang click, kaya laging may kamakailang restore point na pwedeng balikan kung gusto mo. Ang pagkuha ng backup bago ang anumang makabuluhang pagbabago sa database ay isang magandang gawi kahit sino pa ang nagpapatakbo nito.
Kinumpleto nito ang mga ito. Ang bawat site ay nagpapanatili ng sarili nitong MariaDB database na may naka-embed at may single-sign-on na phpMyAdmin at Adminer, suporta para sa maramihang mga database at user, at isang remote access toggle. Ang pagpapanatili ng database ay ang awtomatikong bersyon ng karaniwang gawain — linisin, i-optimize, ayusin — para sa mga pagkakataong mas gusto mong makuha ang resulta kaysa patakbuhin ito nang mano-mano.
Ang mga serbisyo sa platform na ito ay tinutupad sa isa sa dalawang paraan. Ang mga serbisyong tinutupad ng kawani ay lumilikha ng isang gawain sa ating admin queue, na dinidirekta sa tamang departamento na may pagsubaybay sa katayuan at mga update sa customer. Ang pagpapanatili ng database ay awtomatiko: ang pagbili nito ay direktang nagpapagana sa workflow, nang walang hakbang ng tao sa pagitan. Iyon ang buong punto ng pagbuo nito bilang isang workflow sa halip na isang proseso.
Oo. Ang pag-optimize ng database, protektadong query, at backup at restore ay nasa MCP tool catalogue lahat, at ang pagbili ng mga Extra ay may kasamang hakbang sa pagkumpirma. Kumokonekta ang iyong ahente sa pamamagitan ng OAuth 2.1 gamit ang token na naka-scope sa iyong organisasyon at sa iyong mga pahintulot sa RBAC — bawat tool, maaaring bawiin, may limitasyon sa gastusin sa mga bayarang aksyon, at naka-log ang audite ng bawat tawag. Magagawa lamang nito ang kaya mong gawin.
Ang pagpapanatili ng database ay isang bilhing serbisyo na direktang mula sa amin sa halip na kasama sa plano — binibili mo ito kung kailan mo kailangan, sa presyong ipinapakita sa iyong pera sa dashboard, na sinisingil sa iyong billing account o wallet. Ang pagiging kwalipikado ay nakatakda sa bawat linya ng produkto, kaya ang lumalabas sa iyong seksyon ng Extras ay sumasalamin sa linya ng produktong ginagamit mo. Ang lahat ng kailangan mo para subukan ang platform ay nasa 14-araw na pagsubok na walang kailangang card: walang detalye ng pagbabayad, hanggang sa limang site sa Footprint-Free Hosting.
Ang fleet ay nagpapatakbo ng MariaDB na may CloudLinux MySQL Governor, na naglilimita sa paggamit ng database bawat site nang tiyak upang ang mga mabibigat na query ng isang site ay hindi makapagpabagal sa server para sa iba. Kasama ito sa mga limitasyon sa mapagkukunan ng LVE at paghihiwalay ng filesystem ng CageFS. Ang layunin ng disenyo sa buong proseso ay ang containment — nananatili ang mga problema sa kulungang pinagmulan nila.
Magsimula ng 14-araw na pagsubok nang walang card sa Footprint-Free Hosting — walang detalye ng pagbabayad, hanggang limang site — at tingnan kung paano tinutukoy at inaayos ng platform ang mga problemang malalaman mo lang sana dahil sa mabagal na pahina.
Magsimula nang libre