Performance Glossary
Database — Files and State: Why a Site Is Always Two Things
Your restore came back with a site-shaped shell and no content, and you need to understand which half of the site your process quietly skipped.
The short answer
A database is the queryable, structured half of a site — the ordered state where content, accounts and transactions live — kept deliberately apart from the code in your files that decides how they behave.
That split is the reason nearly every hosting operation is two operations. Back up, migrate, clone, restore or promote a staging copy and you are always moving two artefacts, and moving one of them alone produces something that looks like a site and is not.
By the HostingFast team · Reviewed 24 August 2026
100+
Terms, measured not asserted
2 min
To read one entry
Plain
Commands you can run
24/7
Engineers on shift
Hosting is dominated by relational engines — MySQL and MariaDB in the shared world, PostgreSQL on developer plans — which hold everything in tables you can interrogate rather than in files you have to parse.
The consequence people meet first is the staging conflict. Live keeps collecting orders and comments while you work on the clone, so pushing the clone back has to move code and templates without overwriting state that arrived after you took the copy.
Two artefacts, one site
A WordPress migration is a directory of files and a .sql dump, and it is not finished until both have landed and the URLs inside the dump have been rewritten. Copy the files alone and you get a theme with no content; import the database alone and you get content with nothing to render it.
The same arithmetic governs disk usage and backup duration. Files are large and change rarely; the database is small and changes constantly. That asymmetry is why a sensible schedule treats them differently even when a single command captures both.
Pushing staging back without losing data
On a brochure site you can push the whole thing and shrug. On a store you cannot: the orders table has moved on since you cloned, and overwriting it destroys real transactions. Move code, templates and configuration; leave the tables that record what happened while you were working.
Decide that rule before the clone, not during the push. The moment you are looking at a diff between two orders tables at five o'clock, every option available is a bad one.
What a restore actually restores
Run one deliberately, on staging, before you need it. Time it, then open the restored site and check three things: that the content is current, that uploads resolve, and that logins work. A restore nobody has rehearsed is a hypothesis, not a safety net.
Our daily backups run from the panel and cover files and databases together, which removes the commonest failure — restoring one half of a site and discovering the other half is a week older.
Reading its size before it reads you
Track the database's size on a schedule, not on the day something breaks. Growth that outpaces your content is a plugin logging into a table nobody prunes, and it shows up as a slower backup long before it shows up as a slower page.
The reading that matters is the working set against available memory. Once queries stop being answered from the buffer pool, every one of them turns into disk reads, and that is the point at which storage type stops being a specification and starts being your response time.
Hosting terms, defined as operations
Where a term describes something you will actually do, the entry describes the operation: what moves, in what order, and what proves it arrived intact.
Backups here cover files and databases together, restore from your own panel, and sit on the same NVMe storage as the live site.
- Both halves accounted for
- Staging pushes with state in mind
- Restores rehearsed on a clone
- Growth tracked before it bites
Why HostingFast
Standard on every plan
The operation, not the definition
What actually moves during a migration or a restore, in the order it has to move to arrive working.
State treated as state
Why the orders table is not code, and what that changes about promoting a staging copy.
Restores you have practised
How to rehearse one on a clone and what three checks tell you the result is genuinely current.
Growth as an early signal
Reading database size on a schedule so a runaway table surfaces as a trend rather than an incident.
Memory and storage connected
The point at which a working set stops fitting in the buffer pool, and what it does to every query afterwards.
Pointed at the engine underneath
Each entry links to the term that explains the layer your reading has just implicated.
Quick Start
From order to online
- 1
Confirm you have both halves
Before any move, list the file archive and the .sql dump side by side with their sizes. A missing dump is obvious now and invisible after the import.
- 2
Decide which tables stay live
Write down, before you clone, which tables record events rather than configuration. Those are the ones a staging push must never overwrite.
- 3
Rehearse the restore on staging
Run it, time it, then check content freshness, uploads and login. That rehearsal converts a backup policy into a recovery time you can quote.
Built In
Loaded onto every plan
- Daily backups with a self-service restore you run yourself from the panel
- Staging you can clone, break and throw away before anything reaches live
- NVMe on every tier — the entry plan runs the same drives as the top one
- SSH, Git and Composer on the developer-focused plans
- PHP version selectable per site, switched from the control panel in seconds
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- In-place upgrades between plans — no migration when you outgrow one
- A human on support at any hour, including for the awkward questions
- Year one of your domain included when you order annually
- Zero setup fees, on any plan, ever
Frequently Asked
What people ask us most often
Why does a site need a database when static files are faster?
For anything that changes per visitor or per day: edited content, accounts, orders, comments. A genuinely static site skips it and is quicker for exactly that reason. The moment content is being managed rather than hand-edited, something is doing the managing, and that something is a database.
Is editing tables directly in phpMyAdmin ever the right call?
For surgical work, yes — a stuck option, a password reset, a repair the admin screens cannot reach. Export first, change one row, verify in the application. Routine work belongs in the application's own interface, where the code maintaining consistency is still in the loop.
Can I run a restore without opening a ticket?
Yes. Every plan takes a daily backup and the restore runs from your own panel — files, databases or both — at whatever hour you discover the problem. Keeping an additional copy somewhere off our network remains good practice, and nothing in the platform stops you doing it.
Where do the servers sit, and what does that cost me in latency?
London, with redundant power, cooling and several upstream carriers. Distance sets the floor on first-byte time — roughly 5–15 ms for a UK visitor and 70–90 ms from the US east coast. Past that floor the engineering decides everything: NVMe storage, LiteSpeed caching and restrained account density per machine.
Keep reading
Staging Environment
A private clone of live, and the only honest place to measure a change.
MySQL
The engine behind every uncached page, and the slow query log that explains your TTFB.
How to Optimize a MySQL Database
Finding the slow queries, trimming the bloat and measuring what the trim returned.
Web Hosting
cPanel hosting on NVMe with LiteSpeed, free SSL and a migration included.
WordPress Hosting
WordPress with LiteSpeed caching, staging and updates handled for you.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Back up both halves, restore both halves.
Daily backups covering files and databases, self-service restores, and staging to rehearse one on before you need it.
View Web Hosting plans