Database sprawl is a silent productivity killer. As your application grows, so does its data infrastructure. You start with one database, but soon you have separate instances for development, staging, and production. Then come the microservices, each with its own database. Before you know it, you're wrestling with a multi-headed hydra of PostgreSQL, Redis, and MongoDB instances scattered across different cloud providers.
Managing this chaos is a constant drain. You're juggling cloud console credentials, running disparate shell scripts for backups, and battling configuration drift between environments. There’s no single source of truth, just a collection of wiki pages, READMEs, and tribal knowledge.
What if you could manage this entire collection—your database fleet—with the same rigor and simplicity as your application code? This is the promise of Database as Code, a model that brings the power of version control, automation, and repeatability to your data layer.
With the .do Agentic Workflow Platform and the databases.do agent, this paradigm is not just possible; it's simple. Let's walk through how to migrate your existing infrastructure and manage your first fleet as code.
If this sounds familiar, you're not alone. The traditional approach to managing multiple databases is fraught with inefficiency and risk:
This approach doesn't scale. It creates bottlenecks, introduces risk, and slows down your development lifecycle.
Now, imagine a different reality. One where your entire database fleet is defined in a codebase, version-controlled in Git, and managed through a single, unified API.
This is the world of database fleet management with databases.do.
Migrating doesn't mean a massive, risky overhaul. It’s an incremental process of bringing your infrastructure under programmatic control. Here’s how you can get started.
You can't manage what you can't see. The first step is to get a complete, real-time inventory of your existing databases. The databases.do agent makes this trivial.
After initializing the client, you can use the list() method to see every instance the platform is configured to manage.
import { Do } from '@do-sdk/core';
// Initialize the .do client
const ado = new Do();
// Access the databases agent
const myDatabases = ado.use('databases.do');
// List all managed database instances across all clouds
const allInstances = await myDatabases.list();
// [{ id: 'db-prod-users', type: 'PostgreSQL', provider: 'aws', ... },
// { id: 'db-staging-cache', type: 'Redis', provider: 'gcp', ... }]
console.log(allInstances);
This single command gives you a unified view that likely doesn't exist anywhere else in your organization. This read-only step is your safe, powerful entry into data orchestration.
Start small. Pick a low-risk environment, like your development database or the database for a single microservice. Your goal is to codify its creation. Using the create() method, you can define a database instance programmatically.
// Define and provision a new database for the dev team
const devDb = await myDatabases.create({
name: 'dev-user-service-db',
type: 'PostgreSQL',
provider: 'aws',
region: 'us-east-1',
plan: 'small'
});
console.log(`Successfully provisioned: ${devDb.id}`);
You've just replaced a manual, 15-minute clicking process with a single, version-controlled command. This file can be checked into Git, peer-reviewed, and becomes the source of truth for your dev environment.
Here's where the magic happens. A database is useless on its own. It needs a schema, data, and access controls. The .do platform shines by allowing agents to work together.
You can create a workflow that uses the databases.do agent to provision the fleet, then hands off to the database.do agent to manage the specific instance.
// An example agentic workflow script
// 1. Provision the database instance using the fleet agent
const newStagingDb = await myDatabases.create({ ... });
// 2. Use the single instance agent to operate on it
const myDbInstance = ado.use('database.do', { instanceId: newStagingDb.id });
// 3. Connect and run a schema migration
await myDbInstance.connect();
await myDbInstance.query('RUN migrations/v1_initial_schema.sql');
// 4. Seed with test data
await myDbInstance.query('RUN seeds/staging_data.sql');
console.log('Staging environment is ready!');
This is the essence of an agentic workflow. You're composing high-level actions from different specialized agents to automate a complex, multi-step process.
Now that your development and staging workflows are codified, creating a new environment for a feature branch or a new microservice is trivial. You reuse the same workflow script, changing only the input variables.
// Reuse the workflow for a new feature branch environment
// just by changing the name
const featureBranchDb = await createAndSeedDatabase('feature-x-branch-db');
This ensures perfect consistency and allows your teams to move faster than ever before. You've solved configuration drift and turned infrastructure provisioning into a self-service, on-demand capability.
With your key environments codified, you can now use the databases.do agent for true fleet-wide operations.
Your code becomes the central control plane for your entire multi-cloud database infrastructure.
Q: What is the difference between database.do and databases.do?
A: database.do is designed to manage a single database instance, handling its schema, queries, and specific operations. databases.do is a higher-level agent that orchestrates a collection or 'fleet' of multiple database instances, perfect for managing data across microservices, multi-tenant systems, or different environments (dev, staging, prod).
Q: Can I manage different types of databases across multiple clouds?
A: Yes. The databases.do agent acts as a control plane, allowing you to provision, configure, and manage diverse database types (e.g., PostgreSQL, Redis, MongoDB) from different cloud providers (AWS, GCP, Azure) through one unified API.
Q: How is security handled when managing multiple databases?
A: All interactions are secured through the .do platform's centralized authentication and authorization. You can define fine-grained policies to control which users or services have the permission to list, create, or destroy database instances within your fleet.
Migrating from chaotic, manual processes to a Database as Code model is the single most impactful step you can take to scale your data infrastructure reliably. It brings the best practices of software development—automation, version control, and collaboration—to the core of your application.
Ready to tame your database sprawl? Get started with the databases.do agent today and turn your infrastructure chaos into programmatic clarity.
Explore the Documentation and Start Building Your First Fleet