> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Database Every hosted [environment](/environments) can run a managed database, provisioned and operated by Meridian: no database server to run, no credentials to copy. ## Provisioning one Add a database from **Hosting → Database**: pick the engine and, optionally, a name. Provisioning takes up to five minutes, and the credentials are wired into your app automatically. **MySQL** is the engine today, on Meridian's managed Cloud SQL instances. PostgreSQL is marked as coming. The connection reaches your app as the managed `DB_*` [variables](/secrets), injected at deploy time, so nothing is hardcoded, and the credentials never live in your repository. If provisioning or a restore fails, **Delete and recreate** asks you to confirm permanent deletion of the database and all its data. A failed database can still contain data. After deletion, the form lets you create a new, empty database. Closing that form leaves the old database deleted and does not restore its data. ## Connection details The screen shows the connection your app uses inside Meridian: type, host, port, database, user, and the SSL requirement. The password stays hidden until a collaborator with **Credentials: Manage** (`credentials.manage`) access to the app selects **Reveal password**. Each reveal is recorded in the organization audit log. Regular add-on and environment responses never include it. The host is a private address. It is reachable from your hosted app, not from the internet, so these values do not work from your laptop or another cloud. ## Connecting from outside If the other system only needs your data, expose an HTTPS endpoint on your hosted app and call that instead. Your app keeps control of what is read and written, and nothing new reaches the database. When a system outside Meridian does need SQL (your own backend on another cloud, a BI tool, a migration script), give it an **external access credential** from **Hosting → Database → External access**. It connects to `db.the-meridian.app:3306` with two things, and needs both: * A **client certificate**. Its private key is generated in your browser and never sent to Meridian. * A **MySQL user and password** that work on this one database only. Each credential is **read-only** or **read-write**, and can be limited to **allowed networks** (up to 20, in CIDR notation). A database can have at most **5** active credentials, which share **10** connections between them (5 each by default). After **10 failed logins within 15 minutes**, a credential is locked for **15 minutes**. The password and the private key are shown once, when the credential is created or rotated, in a bundle you download. Meridian keeps no copy of either. **Rotating** issues a new certificate and password and stops the old pair on its next connection. **Revoking** deletes the credential's MySQL user, and connections using it stop within 30 seconds. Creating, editing, rotating and revoking credentials needs **Credentials: Manage** (`credentials.manage`). Listing them needs **Hosting: View**. See [External database access](/database-external-access) for the full guide, the settings for each driver, and troubleshooting. ## Reading and writing data There's a SQL console in the dashboard. It's deliberately not a raw pipe: * Every statement is **classified server-side**. The client's claim about what a statement does is never trusted. * **Reads** are available to anyone with **Hosting: View** on the app. * **Any write or DDL statement escalates the whole request** to the **Hosting: Delete** [permission](/customer-permissions), so a viewer can investigate data without being able to change it. Read results are capped at 1,000 rows. When more rows match, the console warns that the result is incomplete. Filter your query or add a `LIMIT` to narrow the results. Structure (tables, columns, indexes) is also readable by an AI client through [Meridian MCP](/mcp-server) (`database_schema_get`), which returns structure only, never rows. ## Backups Backups are listed newest-first with their date and size, and any of them can be restored. How often they run depends on the environment: * **Production** is backed up **daily**. Backups are kept for **7 days on Lite, 30 days on Pro**, and as agreed on Enterprise. Retention comes with the plan: a [hosting upgrade](/add-ons) does not change it. * **Development and staging** are backed up **once a week**, and only the **last 2** backups are kept. **Restoring** replaces the whole database with the chosen backup and briefly interrupts your app while the database is recreated. Restoring needs the **Hosting: Delete** [permission](/customer-permissions), which owners and admins have by default, and it cannot be undone. **Downloading** saves any completed backup as a gzipped SQL dump (`.sql.gz`) you can import into your own MySQL server with `gunzip -c backup.sql.gz | mysql …`. Pick **Download** next to **Restore** and choose a date. Downloading needs the **Database backups: Download** [permission](/customer-permissions), which owners and admins have by default; give it to a member through a [role](/roles), limited to the apps the role reaches. Each download is a fresh link to Meridian's private storage that works for five minutes, so a link copied out of the browser stops working soon after: download again from the dashboard to get a new one. Listing and downloading backups keeps working when the app is locked because its trial ended, its plan lapsed or its organization is suspended: taking your data out never waits on a payment. Restoring one stays closed until the app is paid for again. To take everything the organization holds at once, including the latest dump of every database, use the [organization data export](/organizations#exporting-your-data). ## Metrics and capacity Per database, over today, yesterday, last 7 or 30 days, or a custom range within retention (about 30 days of samples): **storage**, **connections** and **average query time**, plus the instance's connection limit. Charts fill in as Meridian samples the database, so a new one has no trend for a while. Ranges use UTC day boundaries. Storage is a plan meter: 1 GB on Lite and 5 GB on Pro, or 10 GB with Medium and 50 GB with Large, which replace the plan's figure rather than adding to it. Owners are emailed at 90%, 95% and 100%. At the limit nothing is deleted and the app keeps serving, but on one instance with the smallest CPU and memory, and new credentials are blocked, until space is freed or a [hosting upgrade](/add-ons) raises the allowance. See [Billing and usage](/billing). Developer databases are separate: per-developer, provisioned for local work, connected through the [Meridian CLI](/cli) (`meridian dev`), and never shared with a teammate. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.