Public testing phase We’re in a public testing phase — feel free to look around, but we’re not taking orders yet. Ordering opens 1 October 2026. Reserve your place →

Warehouse: a database of your own

Warehouse is a database server of your own, running beside your sites, that you can write to. It appears inside the Databases workbench in Manage — sidebar group "Data Warehouse" — as a group of databases marked RW, next to the read-only site databases. Fill it from a spreadsheet export, from SQL, from a pipeline, or by moving a whole database in; then chart it on a dashboard.

What it is

The warehouse is created together with your first warehouse database — "This also creates your warehouse — a database server of your own next to your sites. It takes about a minute the first time." One account has one warehouse, sized by its tier: Warehouse XS on Starter (512 MB of memory, 5 GB, up to 2 databases), S on Pro (1 GB, 25 GB, up to 10 databases), M on Business (2 GB, 75 GB, up to 20 databases). Every database picks its own engine, MariaDB or PostgreSQL, and gets its own writer login, so a mistake in one never reaches another. A warehouse is included in every plan; the Databases page names your tier and what a bigger one would give.

Create a database

Press New warehouse database in the tree or on the Start tab. The dialog asks for:

  • Name — 3–32 characters: a letter first, then lowercase letters, digits and underscores. This is the SQL name and it cannot be changed later.
  • Engine — MariaDB "is the safe default, and the one WordPress and most PHP applications expect"; PostgreSQL "refuses a value that does not fit a column rather than changing it, and has no unsigned whole-number types."
  • Label (optional) — a friendly name for the tree.

The database shows Creating… while it is provisioned and Removing… while it is dropped. If provisioning fails it shows Failed with "Try creating it again"; the detail stays with us, so if it fails twice, contact us. Dropping a database asks you to type its name — there is no undo apart from the nightly backups — and warns first when a job step, a pipeline or a dashboard panel still uses it.

Tables

New table… on a database opens a column builder: name, type, options (unsigned, nullable, default) per column, an optional id BIGINT auto-increment primary key, and a live preview of the CREATE TABLE that will run — "You can always change the table afterwards with ALTER TABLE in the editor." MariaDB offers TINYINT to BIGINT (signed or unsigned), DOUBLE, DECIMAL(p,s), VARCHAR(n), TEXT, MEDIUMTEXT, DATE, DATETIME, BOOLEAN and JSON; PostgreSQL offers SMALLINT, INTEGER, BIGINT, DOUBLE PRECISION, REAL, NUMERIC(p,s), VARCHAR(n), TEXT, DATE, TIMESTAMP, BOOLEAN, JSONB and JSON. A table has at most 200 columns. Drop table… (or Drop view…) on a table's tab confirms before it runs.

Import data

Import data is in the Start tab header, on every writable database and on every table. The dialog has two steps.

1. Choose the file. CSV, TSV or Parquet, up to 1,024 MB; text files are read as UTF-8. Gzip a text file (.csv.gz) and the same data uploads in a fraction of the time — the limit is counted after it expands. The delimiter is detected, or pick comma, semicolon, tab or pipe; tick "The first row holds column names" when it does. Upload and preview sends the file straight to our EU storage and reads the first rows back.

2. Map the columns. Choose a mode — Create a new table, Append to an existing table (rows are added; the table keeps what it has) or Replace the rows of an existing table (emptied first, then loaded) — and check the column types. For a new table the analyser proposes the narrowest type that fits every value it saw; a boolean column can treat "blank means false". When something will not fit, the import stops before a row is written and lists it under These values will not fit the types you chose. On MariaDB the engine would silently store a number past the ceiling as the ceiling and a word in a number column as 0, so you get Widen the types, Import anyway (accepting those changes) or Check again. On PostgreSQL the whole file would be refused, so only widening or fixing the file is offered.

The import runs as a job tab: "Large files take a while: the file is loaded on the warehouse host with LOAD DATA, one statement, up to 10 minutes. You can keep working in other tabs." While our importers are busy you see your place in the queue. When it finishes, Preview the table opens the result; warnings about changed values are listed with samples.

Write SQL

An editor tab on a warehouse database carries the badge Writable. Besides every read statement it accepts INSERT, REPLACE (MariaDB), UPDATE and DELETE, and CREATE, ALTER, DROP, TRUNCATE and RENAME of a TABLE, VIEW or INDEX — one statement at a time. Grants, LOAD DATA and other file access, SET and session control, transactions, procedures and functions that sleep or lock are refused before they are queued, and the editor says why.

A destructive statement — DROP, TRUNCATE, a DELETE or UPDATE without WHERE, ALTER … DROP, RENAME — pauses at a Confirm this statement dialog with a plain summary such as "DROP TABLE removes the table orders and every row in it." or "DELETE without WHERE removes every row in orders." Nothing runs until you press Run it. Statements run as the warehouse writer and are stopped after 30 seconds (you can raise it to 60 in the editor).

Move a whole database in

To bring an existing MySQL, MariaDB or PostgreSQL database with you, open a warehouse database and choose Move a database here. Two sources: I have an export — a .sql file, a .sql.gz or a pg_dump custom-format archive, uploaded straight to our storage — or Take it from my old host — SFTP (SSH), FTPS or FTP plus the database login, and the export is taken there for a consistent snapshot. Those details are encrypted, handed to the export job exactly once and deleted the moment it starts. The source must be the same engine as the target database. If the target already has tables you choose between Stop, and change nothing and Replace everything in this database; a move that stops part-way is rolled back, so the database you had is the database you still have. When it finishes: "We tell you what arrived — tables and row counts." Prefer to hand it over? The free assisted migration covers databases too.

Limits

The published limits are the standard offer:

  • one warehouse per account at your plan's tier — Starter XS 512 MB / 5 GB / 2 databases, Pro S 1 GB / 25 GB / 10, Business M 2 GB / 75 GB / 20 — MariaDB or PostgreSQL each; Warehouse L (4 GB / 200 GB / 50) and extra disk on request;
  • imports up to 1,024 MB per file (after gzip expands), up to 10 minutes each, tables of up to 200 columns;
  • one writable statement at a time, 30 seconds by default and 60 at most;
  • the read side — 1,000 rows and 30 seconds per query, 2,000 queries a day — is the same as for Databases.

Need more? Contact us — larger limits are available on request, for a fee.

From a script or your AI assistant

The warehouse is in the API and the MCP server, behind the same opt-in data token scope as Databases:

  • POST /api/v1/data/warehouse/databases — create a database (name, engine, label); DELETE /api/v1/data/warehouse/databases/{id} — drop one;
  • GET /api/v1/data/databases lists warehouse databases with the role warehouse; POST /api/v1/data/query reads from them like from any other.

An assistant gets create_warehouse_database and run_warehouse_statement — one writing statement, or a SELECT of up to 1,000 rows; a destructive statement answers needs confirmation with the same summary you would see, and runs only when the assistant calls again with confirmed after you agreed — beside the read-only list_databases, get_schema and run_query. Site databases refuse the writing tool. Next step: Jobs & Pipelines fill warehouse tables on a schedule.