DEV Community

Cover image for Managed Database Add-ons: PostgreSQL, MySQL, MongoDB & MariaDB Without the Hassle
SnapDeploy
SnapDeploy

Posted on • Originally published at snapdeploy.dev

Managed Database Add-ons: PostgreSQL, MySQL, MongoDB & MariaDB Without the Hassle

#webdev #devops #database #docker

TL;DR: SnapDeploy now offers managed PostgreSQL, MySQL, MariaDB, and MongoDB as one-click add-ons. Same dashboard as your containers, browser-based admin UI, auto-injected connection strings. Starts at $24/mo per database. Here's what each engine is good for and how to connect your app.

Every app needs a database eventually. And every developer has experienced this:

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

The launch window closes while you're still reading AWS docs.

The Problem with Database Setup

Most container hosting platforms make you bring your own database. That means:

  • Signing up for a separate database service (RDS, PlanetScale, Supabase, Atlas)
  • Configuring network access between your container and database
  • Managing credentials across multiple platforms
  • Separate billing, separate dashboards, separate monitoring

For solo developers and small teams, this operational overhead kills momentum.

Four Managed Databases, One Dashboard

SnapDeploy's database add-ons live in the same dashboard where you manage containers:

Database Type Best For Web Interface
PostgreSQL Relational (SQL) Complex queries, data integrity, analytics pgAdmin-style UI
MySQL Relational (SQL) Traditional web apps, PHP, broad compatibility phpMyAdmin-style UI
MariaDB Relational (SQL) MySQL-compatible, open-source preference phpMyAdmin-style UI
MongoDB Document (NoSQL) Flexible schemas, JSON data, rapid prototyping Compass-style UI

Which Database Should You Pick?

PostgreSQL — Choose it when you need strong ACID transactions, complex joins, window functions, or extensions like PostGIS. Also handles JSON well alongside relational data. Default choice for new projects.

MySQL — Choose it when your framework expects MySQL compatibility. Most PHP apps, WordPress, and many existing web stacks assume MySQL.

MariaDB — Choose it when you want MySQL protocol compatibility with an open governance model. Drop-in replacement for MySQL with some engine-level improvements.

MongoDB — Choose it when your schema is document-first and changes frequently. Nested JSON documents, rapid prototyping, content management systems.

Not sure? Default to PostgreSQL for relational data. Use MongoDB for document-first designs with variable schemas.

Provisioning: Under a Minute

The setup flow:

  1. Go to Dashboard → Add-ons
  2. Select your database engine
  3. Choose a tier
  4. Click "Create Database"
  5. Wait 30–60 seconds

After provisioning:

  • Connection string is automatically injected into your container's environment variables
  • Web UI endpoint is available at a predictable subdomain
  • Automated backups are enabled by default

No manual credential configuration. No copy-pasting connection strings.

Pricing

Same pricing across all four engines:

Tier RAM CPU Storage Connections Price
Mini 1 GB 0.5 vCPU 5 GB 50 $24/mo
Standard 2 GB 0.5 vCPU 10 GB 100 $44/mo
Pro 4 GB 1 vCPU 25 GB 200 $84/mo

Billed separately from container compute. If your tested peak is 40 connections, start with Standard (100) rather than Mini (50) for headroom.

Connection Strings and Integration

SnapDeploy injects credentials as environment variables — secrets never end up in source control:

PostgreSQL:

DATABASE_URL=postgresql://user:password@db-xxxxx.snapdeploy.dev:5432/dbname
Enter fullscreen mode Exit fullscreen mode

MySQL / MariaDB:

DATABASE_URL=mysql://user:password@db-xxxxx.snapdeploy.dev:3306/dbname
Enter fullscreen mode Exit fullscreen mode

MongoDB:

MONGODB_URI=mongodb://user:password@db-xxxxx.snapdeploy.dev:27017/dbname
Enter fullscreen mode Exit fullscreen mode

Framework Examples

Prisma (Node.js) with PostgreSQL:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
Enter fullscreen mode Exit fullscreen mode

Mongoose (Node.js) with MongoDB:

const mongoose = require('mongoose');
mongoose.connect(process.env.MONGODB_URI);
Enter fullscreen mode Exit fullscreen mode

SQLAlchemy (Python) with PostgreSQL:

import os
from sqlalchemy import create_engine
engine = create_engine(os.environ['DATABASE_URL'])
Enter fullscreen mode Exit fullscreen mode

Django with PostgreSQL/MySQL/MariaDB:

import dj_database_url
DATABASES = {
    'default': dj_database_url.config(conn_max_age=600)
}
Enter fullscreen mode Exit fullscreen mode

The Browser-Based Database Interface

This is the part that saves the most time day-to-day.

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 the web UI, you open the dashboard, click "Open Web Interface", type your SELECT, and see the answer in under a minute.

For SQL databases (PostgreSQL, MySQL, MariaDB):

  • Browse tables and inspect schemas
  • Run SQL queries with syntax highlighting and auto-complete
  • Export as CSV, JSON, or SQL dump
  • View explain plans for slow query analysis
  • Manage users and permissions

For MongoDB:

  • Browse collections and edit documents in the browser
  • Visual query builder + raw JSON queries
  • Index management
  • Export as JSON or BSON

How It Compares

Provider Pros Cons
Self-managed (Docker) Full control You own backups, security, recovery. Data loss on restart.
PlanetScale MySQL-compatible, branching Different paradigm. Separate platform.
Supabase Postgres + real-time Steeper learning curve. Another control plane.
MongoDB Atlas Advanced features Separate billing. Expensive at scale.
AWS RDS Enterprise-grade Complex VPC setup. Expensive for small teams.
SnapDeploy Add-ons Integrated, web UI, auto-configured Not suited for multi-region or enterprise compliance.

Best Practices

  • Never store credentials in code — use the auto-injected environment variables
  • Use connection pooling for high-traffic apps — match pool limits to your tier
  • Enable automated backups (on by default) and export off-platform periodically
  • Test your restore procedure — a backup you've never tested might not work
  • Create separate users for apps vs. admin access
  • Monitor slow queries and resource usage — add headroom before hitting limits

Quick-Start Checklist

  1. Decide: relational (PostgreSQL/MySQL/MariaDB) or document (MongoDB)
  2. Estimate concurrency and storage needs
  3. Choose a tier with headroom
  4. Create separate dev, staging, and production instances
  5. Ensure your app reads connection strings from environment variables
  6. Enable backups and test restore

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

For full documentation, see the Add-on Services docs. For pricing details, see the Add-on Pricing page.

Top comments (0)