NEXUS AI Database: The Complete Guide

NEXUS AI Database gives your apps a production database without running a database server yourself. You create it with one command, attach it to a deployment, and NEXUS AI injects the connection settings, handles backups, and lets you query and repair it, including through AI assistants.

What it is

NEXUS AI Database is the database layer of the NEXUS AI deployment platform. It comes in two forms that share one workflow: create, attach to an app, redeploy, connect.

Two related pieces round it out:

• Deployment database services. Databases provisioned alongside a deployment (PostgreSQL, MySQL, Redis, MongoDB) get on demand and daily backups, downloads, and restores.
• External database sources. You can connect an existing PostgreSQL or MySQL database you run elsewhere to use NEXUS AI's schema inspection, safe querying, and AI assisted fixes on it.

Why use it

The main reason is that the database lives in the same place as the app, so wiring, secrets, and backups stop being separate chores.

• No manual connection strings. Attaching a database injects DATABASE_URL, DATABASE_HOST, DATABASE_PORT, DATABASE_USER, DATABASE_PASSWORD, and DATABASE_NAME into the app on its next deploy. A custom prefix lets one app use several databases.
• One tool for every cloud. The same commands create a database on NEXUS AI or in AWS, GCP, or Azure, so moving from a prototype to a cloud instance does not change your workflow.
• Backups without extra tooling. Hosted services get daily automated backups with at least 7 days of retention, and cloud databases get snapshots.
• No lock in. Backups download as standard files: pg_dump custom format, mysqldump, mongodump archives, and Redis RDB, so you can restore anywhere.
• Safe access for people and AI assistants. Read only queries, guarded writes, dry runs with EXPLAIN, and AI proposed schema fixes all work from the CLI, the dashboard, or an MCP client such as Claude.

Who it is for

It fits any team that deploys on NEXUS AI and would rather not run database servers. Creating a standalone database requires a paid NEXUS AI plan.

When to use which option

Start hosted on NEXUS AI for speed; move to a managed cloud instance when you need MySQL, more storage control, or private cloud networking.

Two moments call for action regardless of option: before a risky migration (take a snapshot or backup first) and before launch (run a restore drill, covered below).

How it works

Whichever option you pick, the database reaches your app through the same four steps.

[embedded content: NEXUS AI database lifecycle · create to connected app]

Creation is asynchronous, so a new database is attachable only once its status reads AVAILABLE. Attaching changes nothing until the app is redeployed, because the connection variables are injected at deploy time; detaching likewise takes effect on the next deploy.

How to set one up

Setup takes five steps, from the NEXUS AI CLI or from any MCP client connected to NEXUS AI (tool names in brackets).

1. Create the database (nexusai_managed_db_create). Give it a name (3 to 63 lowercase letters, digits, or hyphens) and an engine: POSTGRES, MYSQL, or REDIS.
   • For a database on NEXUS AI, set provider to NEXUS_DOCKER. Optional: engineVersion (17, 16, or 15 for Postgres; 7 for Redis), databaseName (default appdb), username (default nexusadmin), and password (12 to 128 characters; if omitted, one is generated and shown once).
   • For a cloud database, set provider to AWS_RDS, GCP_CLOUD_SQL, or AZURE_DATABASE, plus a required engineVersion (for example 17.10 or 8.0.46 on AWS, 16 or 8.0 on GCP). Optional: instanceClass (such as db.t3.micro), allocatedGb (20 to 1,000, default 20), region, and on AWS networkMode (public or vpc).
2. Wait until it is AVAILABLE. Provisioning runs in the background; poll the status before attaching.
3. Attach it to your app (nexusai_managed_db_attach) with the database and deployment IDs. Use envPrefix to rename the variables, for example ANALYTICS for a second database.
4. Redeploy the app (nexusai_deploy_redeploy) so the new variables are injected.
5. Verify the connection by running SELECT 1 with nexusai_managed_db_query, or by checking the app's logs.

A real example: SenalOps runs on NEXUS AI with a managed PostgreSQL database and two services, created like this:

nexusai managed-db create --name senalops-db
nexusai secrets create DATABASE_URL "postgres://..."
nexusai deploy create --name senalops-web    --source apps/web    --start "pnpm --filter @ai-monitring/web start"
nexusai deploy create --name senalops-worker --source apps/worker --start "pnpm --filter @ai-monitring/worker start"
nexusai deploy logs   --name senalops-worker

For local development against a hosted database, nexusai_managed_db_connection reveals the host, user, and password; every reveal is audit logged. Cloud databases do not support reveals, so attach them to a deployment instead.

Backups, snapshots, and restore

Database services attached to deployments use file backups you can download; managed cloud databases are backed up by their cloud provider, and NEXUS AI adds on demand snapshots that restore into a new instance.

Two restore behaviors matter before you press the button:

• Restoring a service overwrites it. Both nexusai_db_restore and nexusai_db_restore_to replace the data on the target service. Take a fresh backup first if the current data might still be needed.
• Snapshot restores are safe by design. A managed cloud restore always creates a new database with a name you choose, so you can inspect it, then attach it in place of the old one.

Prove your backups restore

A backup that has never been restored is a hope, not a plan. Run a restore drill before launch, after major schema changes, and at least quarterly:

1. Restore the latest backup or snapshot into a new, non production database.
2. Point a temporary DATABASE_URL at it and run your migrations.
3. Start the app against it and load a representative account.
4. Record how long the restore took (recovery time) and how old the backup was (recovery point).
5. Delete the scratch database, since it holds production data.

To automate this, a tool such as Senal Recover validates every backup and can restore each one into a scratch database on a schedule.

Querying and AI assisted schema fixes

NEXUS AI separates reading from changing, so you or an AI assistant can explore data freely while every write needs an explicit step.

A typical AI assisted repair looks like this: a deploy fails with a database error such as a missing column; you pass the log snippet to nexusai_db_propose_fix, read the proposed DDL, dry run it with nexusai_db_query_preview, then apply it. Functions, triggers, views, and procedures are supported, including bodies that use $$ quoting.

Security and access

The safest setup keeps credentials out of people's hands: attach the database to the app and let NEXUS AI inject the connection settings.

• Networking. On AWS, public mode (the default) exposes an endpoint limited by a CIDR allowlist, while vpc mode makes the instance reachable only from the App Runner VPC connector. Azure databases are always private on a VNet. Hosted databases attach to apps running on NEXUS AI.
• Credentials. A generated password for a hosted database is shown once at creation, so store it in a secret manager right away. Passwords you set must be 12 to 128 characters with no spaces, quotes, or backslashes.
• Audit trail. Revealing a hosted database's connection details is audit logged, so you can see who accessed credentials and when.
• Least privilege for automation. Read only queries need no special scope; writes and DDL through nexusai_managed_db_execute require the manage scope. Give AI assistants and scripts read access unless they truly need to change data.
• Scoped per organization. Databases, backups, and restores belong to your NEXUS AI organization; a backup can only be restored into a service in the same organization.

Limits and open questions

Most surprises come from defaults and from changes that wait for a redeploy.

• Standalone databases require a paid NEXUS AI plan.
• The default provider is AWS RDS. Set NEXUS_DOCKER explicitly when you want a database on NEXUS AI itself.
• Redis is available only on NEXUS AI hosted; MySQL only on cloud providers.
• Attaching and detaching take effect on the next deploy, not immediately.
• Deleting a database is permanent. Deleting a hosted database still attached to apps needs force, and those apps lose their connection variables on their next deploy.
• Cross service restore works PostgreSQL to PostgreSQL only and overwrites the target.

NEXUS AI confirmed the answers to these questions:

• [ ] Is point in time recovery available, and to what granularity? No. NEXUS AI does not support point in time recovery. Managed cloud databases can use their provider's own point in time recovery instead: AWS RDS restores from its automated backups, GCP Cloud SQL once point in time recovery is enabled on the instance, and Azure Database from its automated backups. Each restores into a new instance within the provider's retention window, and you set it up and run it in that cloud's console, not through NEXUS AI.
• [ ] Where are backups stored, and with what durability? Backups are stored in the tenant's own storage. Only the tenant that created a backup can access it, and it can be restored only into the same organization.
• [ ] What recovery time and recovery point does NEXUS AI commit to? No commitment is stated. Because point in time recovery is not supported, the recovery point is the most recent backup or snapshot.
• [ ] Do managed cloud databases get automatic snapshots, and do snapshots work on GCP and Azure as they do on AWS? Automatic backups are handled by the cloud provider, not by NEXUS AI. NEXUS AI snapshots on GCP and Azure do not work the way they do on AWS.
• [ ] Are high availability replicas offered, and on which plans? No. High availability replicas are not supported on any plan.
• [ ] What does each database option cost per plan? Databases are included with the NEXUS AI plan.

Sources: NEXUS AI's platform tool definitions (database, backup, and deployment tools) and the SenalOps production runbooks for NEXUS AI deployment and backup verification.