Skip to main content

Database Management

KIOPS's [Database Management] page goes beyond connection registration and synchronization. It also lets you keep SQL dump files you already have in a storage area, and reuse a stored dump across multiple environments.

The guides in this category focus on "what order do I actually click in" rather than "where is the button". For a page-level reference, see the [Database Management] page guide (pages/database). This category collects only end-to-end scenarios that operators can follow from start to finish.

Before You Start: Terms to Know​

A short primer on terms that appear repeatedly in this category. Refer back here when a term first appears in the text.

  • SQL dump: A file that captures a DB's schema and data as a sequence of SQL statements. Created with mysqldump or pg_dump. Think of it as a "snapshot of the DB" that you can carry around on a USB stick.
  • Target DB: The destination DB the dump will be applied to. Pick one of the connections registered in the DB Connections tab.
  • Data package: A SQL dump file kept inside KIOPS. Once uploaded it can be replayed against any environment - the "USB stick on the shelf" concept.
  • append / replace: The two import modes. append adds on top of existing data; replace wipes the target schema first and refills it.
  • Status tag: The current state of a package - one of ready / applying / applied / failed / deleted. Apply progress is tracked via the status tag on the Data Package tab.

Prerequisites​

You need the Database Management permission

Every task in this category starts on the [Database Management] page. If the page is missing, ask your organization admin for the Database Management permission.

Before you begin, make sure the following are in place.

  1. DB connection registered: The target DB must already be registered on the [Database Management] > DB Connections tab and pass a connection test.
  2. Target DB password ready: The target DB password (plus SSH / Jump passwords if applicable) is entered once more inside the apply modal.
  3. A SQL dump file you have: You need a .sql / .sql.gz file you created yourself or received from someone.
  4. Storage headroom: To keep a package, your organization's storage must be within the 5GB quota.

Scenario List​

Working with SQL dumps in KIOPS splits into three flows. Pick the guide that matches your situation.

1. Upload a SQL Dump File​

Use the Upload SQL File button on the [Database Management] > Data Package tab to keep a SQL dump (.sql / .sql.gz) you created or received in the storage area.

  • Picking a file uploads it immediately - no modal - and registers it as a data package.
  • Upload size up to 1GB.
  • Applying it is a separate step (package apply) after the upload.

2. Using the Data Package Storage​

Keep an uploaded dump inside KIOPS and apply it to dev / staging / prod in turn, or download it for external use.

  • Use this when the same dump must be replayed multiple times.
  • Apply via the Apply button (PackageApplyModal) on a package row, or the package-apply path in the Migration tab.
  • A 5GB quota per organization applies, and applied import packages are auto-cleaned after 30 days.

3. What to Watch When DB Types Differ​

MySQL/MariaDB and PostgreSQL have incompatible SQL syntax.

  • Only same-engine combinations (MySQL ↔ MariaDB included) can be applied without conversion.
  • The package apply screen blocks cross-engine combinations.
  • The backend has engine conversion logic, but it is not exposed in the current UI.
Always back up production before applying

Tasks in this category include operations that wipe or overwrite target tables. Before touching a production DB, take a backup from the [Database Management] > Backup Management tab, or rehearse the flow on staging.

What to Do Next​

After skimming all three guides, the recommended adoption order is:

  1. Upload a SQL Dump File - Start with the simple upload flow that registers a dump you have as a data package.
  2. Using the Data Package Storage - Extend a stored dump into a dev / staging / prod rollout pattern.
  3. What to Watch When DB Types Differ - Learn the compatibility constraints between different DB products.