# Databases The Markdown copy of . Ask your agent for a database and Yeeted runs it, hands your app the connection details, and lets you take the data anywhere. Yeeted runs managed databases for you - **MySQL, Postgres, MariaDB, MongoDB, and Redis**. Each project gets its own database and credentials; you never provision or patch a server. Databases come with the Beta plan, and with the Developer plan and up once paid plans open; the Free plan has none. ### Attach one Ask your agent, or declare it in your [`yeeted.yaml`](https://yeeted.ai/docs/configuration.md). For example: ``` "Give my app a Postgres database." "Attach Redis for caching." ``` ### Connect to it Yeeted injects the connection details into your app as environment variables, so your code just reads them: - `DATABASE_URL` - a ready-to-use connection string for Postgres, MySQL and MariaDB; MongoDB and Redis get `MONGODB_URL` and `REDIS_URL` instead - Engine-specific vars like `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB` - Redis only: every key your app uses must start with `REDIS_KEY_PREFIX`; the instance refuses any other key You can see and manage every database from the **Databases** tab in your dashboard. Storage and memory limits depend on your environment and plan (see [Plans and limits](https://yeeted.ai/docs/plans-and-limits.md)). ### Export a database Your data is yours to take anywhere. Click **Export** on a Postgres, MySQL, MariaDB or MongoDB database (or ask your agent to “export my database”) and you get a download link to a standard dump file that imports into any compatible database - on Yeeted or anywhere else. Links expire after an hour, and each database can be exported about once an hour. Available on every plan that includes a database. Redis can't be exported: one instance holds every project's keys, so it can't dump yours on their own. ### Mirror to your own database On Small Business plans and up (after the beta), Yeeted can keep a database of your own - your RDS instance, your own server, another provider - continuously up to date with your Yeeted database. Set a target connection URL and a sync interval (every 15 minutes by default). Postgres, MySQL, MariaDB and MongoDB can be mirrored; Redis cannot be mirrored, because it has no per-project dump: ``` "Replicate my postgres to postgres://user:pass@db.example.com:5432/mirror" ``` ```mermaid flowchart LR A[(Your Yeeted database)] -->|"sync every 15 min"| B[(Your own database
RDS · your server · anywhere)] ``` Each sync refreshes *only your project's own tables* on the target - anything else living in that database is left alone. Check sync status any time from the Databases tab or by asking your agent to list databases; stop any time with “stop replicating” (your copy keeps whatever was last synced). ### Rotate a password Click **Rotate password** on a database (or ask your agent) whenever a credential may have leaked, or just as routine hygiene. A new credential is issued immediately and the old one stops working; redeploy right after so your app picks up the new connection details. The new password is shown once, in case you use it outside Yeeted. ### Delete a database Click **Delete** on a database (or ask your agent, which uses the `database_delete` tool and must get your go-ahead first). An agent can only do this if you allowed it to delete databases, when you connected it or later on the dashboard's Connect page; deleting is off until you do. Deleting drops that project's database, its user and **all of its data** from the server, permanently, so download a copy first if you may need it (Export works for every engine except Redis). You confirm by typing the database's name. Only the database goes: the database server keeps running and other projects' databases are untouched. Copies taken earlier are not deleted with it: an export link lasts about an hour, automatic pre-restore and pre-move snapshots are kept for 14 days, and checkpoint snapshots stay with their checkpoint, so you can attach a new database and restore one while it exists. If your `yeeted.yaml` still asks for the database, the next deploy creates a new, empty one. A live app of the project in that environment (running, starting, deploying or building, crashlooping, a failed deploy whose previous version still serves, or held) has to be stopped first: Delete is refused while one is live and tells you which. Stop the service with Stop on the dashboard's Services page, or one version with its Stop in the Versions table on the service page (no MCP tool stops a deployment). A held app was stopped by Yeeted's enforcement and comes back when the hold is released: contact support to resolve the hold first. A stopped app does not block, but a stopped development app wakes on its next request and any stopped app can be started again, and then it comes back without this database (or with a new, empty one if its `yeeted.yaml` asks for one). Delete is also refused, with nothing deleted, while the database syncs to a database of your own (stop the sync first), while it is busy with another operation or its server is under maintenance or failing over, under a legal hold, or while the server's standby copy is unreachable. On a server with a standby, the database's login is removed there too. ### Test against real data On Small Business plans and up (after the beta), every development preview gets its own test database seeded with a snapshot of your *production* data, so you test against real-shaped data while real users are never touched. Refresh it on demand: “refresh my test data.” Redis is not copied from production.