Migrate to RunxBuild and earn up to $50 in hosting credit on your first deposit.

Calculate your savings
unxBuild
Log in Get Started
Docs Documentation
wordpress 00 / 29

Database

Every WordPress site on RunxBuild has a database browser in the dashboard, so the usual reasons for installing phpMyAdmin do not apply. Open the site and select the Database tab.

There are two modes: Browse for working through tables and rows, and SQL for running a query directly.

Browse mode

The table list loads on the left. Select a table to page through its rows, fifty at a time.

From here you can:

  • Insert a row — fill the columns and save.
  • Edit a row — change values in place.
  • Delete a row — removed immediately, with a confirmation first.

This is the right mode for the small, surgical fixes that WordPress occasionally needs: correcting a wp_options value after a bad plugin setting, clearing a stuck transient, or fixing a siteurl that points at the wrong domain after a migration.

Changing table structure

You can also add a column, edit an existing column (name, type, whether it accepts null, default value), and delete a column.

Structure changes apply to the live database immediately. WordPress core tables have a schema that plugins and core updates both depend on — changing those is a good way to break a site in a way that is hard to trace. Restrict structure edits to tables your own code owns.

SQL mode

SQL mode runs a query against the database and shows the result. A SELECT returns rows; anything else reports how many rows it affected.

This writes directly to your live site’s database. There is no staging step and no undo. An UPDATE without a WHERE clause will rewrite every row in the table, and the first sign of trouble will be the site itself.

Two habits make this safe enough to use:

  1. Export before you write. A table export takes seconds and turns a mistake into an inconvenience.
  2. Run it as a SELECT first. Swap the UPDATE for a SELECT with the same WHERE clause and confirm it matches the rows you expect — and only those.

Large result sets are truncated for display. That is a display limit only; the query itself ran in full.

Export and import

Export downloads a .sql dump. You can take the whole database, or a single table when you only need one.

Import uploads a .sql file and applies it. The table list and the current view refresh when it finishes.

Worth being clear about: an import applies whatever the file contains. A dump taken from another site carries that site’s URLs in wp_options and throughout wp_posts, so importing one into a different domain without a search-and-replace leaves a site pointing at the wrong host. Export first, so you have the state you are about to replace.