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.
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.
| Option | Where it runs | Engines | Networking |
|---|---|---|---|
NEXUS AI hosted (provider NEXUS_DOCKER) |
On NEXUS AI itself, beside your apps on the primary host | PostgreSQL 17, 16, 15; Redis 7 | Attaches to apps deployed on NEXUS AI (local Docker apps) |
| Managed cloud | A managed instance in AWS RDS, GCP Cloud SQL, or Azure Database, created and wired by NEXUS AI | PostgreSQL, MySQL | AWS: public with an allowlist, or private VPC. GCP: org credentials. Azure: always private |
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, andDATABASE_NAMEinto 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_dumpcustom format,mysqldump,mongodumparchives, 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.
| Who | What they get |
|---|---|
| Solo founders and small startups | A PostgreSQL or Redis database next to the app in one command, with backups on by default |
| Product and full stack teams | Connection settings injected at deploy time, so no secrets are copied by hand between environments |
| Platform and DevOps teams | One workflow across NEXUS AI, AWS, GCP, and Azure, plus snapshots and restores into new instances |
| Regulated or security minded teams | Private networking (AWS VPC, Azure VNet), audit logged credential access, and portable backups |
| AI engineers and AI assisted developers | MCP tools that let an assistant inspect schemas, run safe queries, and propose fixes with confirmation |
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.
| Situation | Choose | Why |
|---|---|---|
| Prototype, MVP, or internal tool | NEXUS AI hosted PostgreSQL | Ready in minutes, no cloud account needed, attaches to apps on NEXUS AI |
| Cache, queues, or sessions | NEXUS AI hosted Redis 7 | Runs beside the app with password auth and an optional ACL user |
| Production app that needs MySQL | Managed cloud (AWS RDS or GCP Cloud SQL) | MySQL is available only on cloud providers |
| Data must stay on a private network | AWS with vpc networking, or Azure |
AWS VPC mode is reachable only from the App Runner VPC connector; Azure is always private |
| You need a chosen size or region | Managed cloud | Set instance class, 20 to 1,000 GB of storage, and region |
| An existing database stays where it is | External database source | Adds inspection, safe queries, and AI fixes without migrating data |
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).
- Create the database (
nexusai_managed_db_create). Give it aname(3 to 63 lowercase letters, digits, or hyphens) and anengine:POSTGRES,MYSQL, orREDIS.- For a database on NEXUS AI, set
providertoNEXUS_DOCKER. Optional:engineVersion(17, 16, or 15 for Postgres; 7 for Redis),databaseName(defaultappdb),username(defaultnexusadmin), andpassword(12 to 128 characters; if omitted, one is generated and shown once). - For a cloud database, set
providertoAWS_RDS,GCP_CLOUD_SQL, orAZURE_DATABASE, plus a requiredengineVersion(for example17.10or8.0.46on AWS,16or8.0on GCP). Optional:instanceClass(such asdb.t3.micro),allocatedGb(20 to 1,000, default 20),region, and on AWSnetworkMode(publicorvpc).
- For a database on NEXUS AI, set
- Wait until it is AVAILABLE. Provisioning runs in the background; poll the status before attaching.
- Attach it to your app (
nexusai_managed_db_attach) with the database and deployment IDs. UseenvPrefixto rename the variables, for exampleANALYTICSfor a second database. - Redeploy the app (
nexusai_deploy_redeploy) so the new variables are injected. - Verify the connection by running
SELECT 1withnexusai_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.
| Deployment database services | Managed cloud databases | |
|---|---|---|
| Take a backup | On demand (nexusai_db_backup) |
Snapshot on demand (nexusai_managed_db_snapshot_create), asynchronous |
| Automatic backups | Daily schedule (nexusai_db_backup_schedule), retention 7 days minimum, can be raised |
Handled by the cloud provider (AWS, GCP, or Azure) under its own backup settings |
| Download | Signed URL valid 30 seconds to 1 hour (default 5 minutes) | Not available |
| File format | pg_dump custom, mysqldump, mongodump tar.gz, Redis RDB |
Provider snapshot |
| Restore | Into the same service, or into another service in the org (PostgreSQL to PostgreSQL only) | Into a new instance; the source is left unchanged |
Two restore behaviors matter before you press the button:
- Restoring a service overwrites it. Both
nexusai_db_restoreandnexusai_db_restore_toreplace 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:
- Restore the latest backup or snapshot into a new, non production database.
- Point a temporary
DATABASE_URLat it and run your migrations. - Start the app against it and load a representative account.
- Record how long the restore took (recovery time) and how old the backup was (recovery point).
- 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.
| Task | Tool | Safeguard |
|---|---|---|
| Read data from a managed database | nexusai_managed_db_query |
Only SELECT; writes and DDL are rejected. Private databases are reached through an in VPC or VNet proxy |
| Change data or schema in a managed database | nexusai_managed_db_execute |
Requires the manage scope; SQL is safety checked |
| Connect an existing database | nexusai_db_source_connect |
Tests the connection first; supports SSL modes from disable to verify-full |
| See the schema | nexusai_db_inspect_schema |
Returns a normalized schema graph, cached until you refresh it |
| Try a statement without running it | nexusai_db_query_preview |
Runs EXPLAIN plus a safety analysis |
| Run a statement on a connected database | nexusai_db_query_execute |
UPDATE and DELETE need a WHERE; any write or DDL needs confirmed=true; up to 10,000 rows returned |
| Fix a schema error from your logs | nexusai_db_propose_fix, then nexusai_db_apply_fix |
The fix is proposed as DDL for review and applied only on confirmation |
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,
publicmode (the default) exposes an endpoint limited by a CIDR allowlist, whilevpcmode 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_executerequire 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_DOCKERexplicitly 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.
About NEXUS AI
NEXUS AI is an agentic AI app builder and full-stack deployment platform. Explore the AI App Builder, learn more on the About page, read the documentation, or contact the team through nexusai.run/contact.
Start for free · Read the documentation · About NEXUS AI · Contact