Managed Database Add-ons: PostgreSQL, MySQL, MongoDB, MariaDB

You just need a Postgres database for your container. Thirty minutes later you're deep in VPC configuration, security groups, and IAM roles while your launch window closes.

That moment is not rare. It exposes the operational tax of running data services: time lost to configuration, context switching between platforms, and brittle scripts that break under load. Managed databases should remove that tax and keep your time focused on product.

SnapDeploy's managed database add-ons put your containers and your data under one control plane. This guide covers which engine to choose, how provisioning and integration work, what the browser-based interface can do, operational best practices, and how the offering compares to alternatives.

What the Add-ons Deliver

Four managed database engines live in the same dashboard where you run containers:

The design goals are consistent across engines: one-click provisioning, automatic injection of connection strings into container environment variables, a browser-first web interface for routine admin, and predictable billing with clearly defined tiers.

Which Database Should You Pick?

PostgreSQL

Choose it when you need strong data integrity, ACID transactions, complex joins, window functions, or extensions like PostGIS for geographic data. Postgres also handles JSON alongside relational data well, making it a flexible default for new projects.

MySQL

Choose it when your framework expects MySQL compatibility. Most PHP apps, WordPress, and many existing web stacks assume MySQL. It handles CRUD workloads well and has straightforward replication and migration paths.

MariaDB

Choose it when you want MySQL protocol compatibility with an open governance model. MariaDB offers different engine-level optimizations and certain storage engines that MySQL lacks. If you use MySQL today and prefer open-source licensing, MariaDB is a drop-in replacement.

MongoDB

Choose it when your schema is document-first and changes frequently. If you're modeling nested JSON documents, iterating rapidly on data structures, or building a content management system where flexibility matters more than rigid schemas, MongoDB fits.

Provisioning: a Few Clicks, a Few Minutes

The workflow is intentionally simple:

1. Go to Dashboard → Add-ons
2. Select your database engine: PostgreSQL, MySQL, MariaDB, or MongoDB
3. Choose a tier (see pricing below)
4. Click "Add Database"
5. Wait a few minutes while the instance and its persistent storage are provisioned

After provisioning completes:

• A connection string is automatically injected into your container's environment variables
• The admin UI (pgweb, phpMyAdmin or mongo-express, depending on the engine) opens from the add-on card
• Daily backups are enabled by default

Pricing

Tiers are identical across all four engines:

Database add-ons are billed separately from container compute. Plan for headroom in production—if your tested peak is 40 connections, start with Standard (100 connections) rather than Mini (50).

Try Any Database for $1: DB Sprint Pack

Not sure which database tier or even which engine fits your workload? The DB Sprint Pack is a one-time $1 USD / ₹99 INR purchase that provisions any one of six managed engines — PostgreSQL 16, MySQL 8, MariaDB 11, MongoDB 7, Redis 7, or RabbitMQ 3 — at full Mini-tier capacity for 12 hours. Persistent storage on EFS, daily backups (same as monthly plans), 50 connections, full privileged access. No subscription, no auto-renewal, no card hold.

Connection Strings and Integration

SnapDeploy injects credentials as environment variables so secrets never end up in source control. Your app reads the connection string at runtime:

DATABASE_URL=postgresql://user:password@db-xxxxx.snapdeploy.app:5432/dbname

DATABASE_URL=mysql://user:password@db-xxxxx.snapdeploy.app:3306/dbname

MONGODB_URI=mongodb://user:password@db-xxxxx.snapdeploy.app:27017/dbname

Framework Examples

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

const mongoose = require('mongoose');
mongoose.connect(process.env.MONGODB_URI);

import os
from sqlalchemy import create_engine
engine = create_engine(os.environ['DATABASE_URL'])

import dj_database_url
DATABASES = {
    'default': dj_database_url.config(conn_max_age=600)
}

const mysql = require('mysql2');
const connection = mysql.createConnection(process.env.DATABASE_URL);

Because the platform injects the connection string, your code stays agnostic to credential rotation. No secrets in config files, no manual env setup.

The Browser-Based Database Interface

This is one of the most powerful parts of the offering. The built-in web UI removes setup friction that normally costs you 20–30 minutes before you can even look at your data.

Here's a real scenario: it's 11 PM, a user reports a bug, and you need to check a database row. Without a web interface, you'd install pgAdmin, configure the connection, find the right table, and run a query. With SnapDeploy, you open the dashboard, click "Open pgweb" (or phpMyAdmin and mongo-express for the other engines), type your SELECT query, and see the answer without installing anything. No local tooling, no SSH.

What You Can Do in the Browser

For SQL databases (PostgreSQL, MySQL, MariaDB):

• Browse tables and inspect schemas — see columns and types at a glance without writing a single query
• Run SQL queries directly — a query editor in the browser, with a history tab so you can rerun recent checks
• Export data — pgweb downloads results as CSV, JSON or XML; phpMyAdmin also imports and exports SQL and CSV dumps
• View explain plans — spot slow queries and missing indexes without setting up local performance tooling
• Manage users and privileges — phpMyAdmin has a user-accounts screen; in pgweb you run the GRANT statements yourself

For MongoDB:

• Browse collections and edit documents — view, filter, and modify documents directly in the browser
• Simple or raw JSON queries — filter with a key/value form or paste a raw JSON query for complex filters
• Index management — create, view, and drop indexes to optimize query performance
• Export as JSON or BSON — for backups, migrations, or local analysis

Security and Operational Best Practices

• Never store credentials in code. Read them exclusively from the environment variables injected by the dashboard.
• Use connection pooling. For high-traffic apps, pools reduce connection churn. Make sure your pool limits match your tier's connection limit.
• Enable automated backups immediately. They're on by default, but also export backups off-platform periodically for an extra safety net.
• Test your restore procedure. A backup you've never tested is a backup that might not work. Import into a staging instance and verify.
• Create separate users for apps vs. admin. Grant only the permissions each role needs. Rotate admin credentials on a schedule.
• Monitor slow queries and resource usage. Watch disk IOPS, CPU, and connection counts. Add headroom before you hit limits.

Migration: Moving Your Existing Database

If you have an existing database elsewhere, migration follows four steps:

1. Export from source: Use pg_dump for Postgres, mysqldump for MySQL/MariaDB, or mongodump for MongoDB.
2. Provision a staging instance: Create a Mini tier add-on to test the import before touching production.
3. Import and validate: Restore the dump, run schema checks, and smoke test with sample queries.
4. Cutover: Update the container environment variable to the new connection string. Monitor for 72 hours and review slow query logs.

How It Compares to Alternatives

Choose SnapDeploy add-ons when you want low-friction, consolidated management of containers and databases under one dashboard. Consider external providers when you need advanced multi-region replication, specialized compliance certifications, or storage IOPS beyond the platform tiers.

Quick-Start Checklist

1. Confirm your data model: relational (PostgreSQL/MySQL/MariaDB) or document (MongoDB)
2. Estimate concurrency and storage needs, including headroom
3. Choose a tier based on RAM, connections, and storage
4. Create separate dev, staging, and production instances
5. Ensure your app reads connection strings from environment variables
6. Enable automated backups and schedule periodic off-platform exports
7. Test your restore procedure in a non-production environment

Conclusion

Databases should accelerate your product, not introduce new bottlenecks. Managed add-ons that sit next to your containers reduce friction at every stage: provisioning, connection management, day-to-day administration, backups, and billing.

Start by provisioning a Mini tier in a staging environment and migrating a representative dataset. Validate performance, backups, and connection pooling. After 72 hours of monitoring, scale to production with appropriate headroom.

One dashboard for your containers and your data—that's the point.

For step-by-step documentation, see Add-on Services. For environment variable management, see Environment Variables. For pricing details, see Pricing.