A database deployment model describes where a database actually runs and who is responsible for keeping it running. In a locally hosted (on-premises) model, your organization owns or leases the physical servers, storage, and network gear, installs the database software, and handles patching, backups, tuning, and physical security. In a cloud-based model, a provider such as AWS, Microsoft Azure, or Google Cloud supplies the infrastructure and, in managed Database-as-a-Service offerings, much of the routine administration as well.
This distinction matters in COP4708 because almost every design decision later in the module depends on it: how you pay for capacity, how you scale under load, how you achieve availability and disaster recovery, and which security and compliance tasks remain yours. Deployment choice is rarely about which model is technically 'better' — it is about matching infrastructure characteristics to an organization's budget, staffing, regulatory environment, and growth expectations.
As you watch the videos below, keep a running comparison across a few key dimensions: cost structure (upfront capital spending versus ongoing operational spending), scalability, maintenance effort, availability, security, and control. Also pay attention to the division of labor — note each time a speaker mentions a task the provider handles versus one the customer still owns, since that idea becomes the shared responsibility model later in the module.
An IBM Technology explainer on Database-as-a-Service: what a managed cloud database service is, how it differs from installing and running a database yourself, and the trade-offs involved in adopting it. Based on its title and description, it likely walks through provisioning, provider-handled maintenance tasks such as patching and backups, and the situations in which DBaaS is or is not a good fit.
It directly addresses the cloud-based side of the deployment comparison from a major cloud provider's perspective, and its framing of what the provider manages versus what you still manage previews the shared responsibility idea central to this topic.
ByteByteGo surveys how engineers choose a database for a given workload, typically covering database families and the requirements — data model, scale, consistency, and query patterns — that drive the decision. The discussion situates deployment and hosting choices within the broader selection process rather than treating them in isolation.
It gives useful context for why deployment model is one dimension among several in a database decision, and ByteByteGo's clear, animated system-design style makes the comparison criteria easy to retain.
This ByteByteGo video unpacks what 'cloud native' actually means, likely touching on managed services, elasticity, containers, and designing systems to take advantage of cloud infrastructure rather than simply relocating existing servers. It helps separate genuine cloud architecture from a lift-and-shift migration.
It supplies the architectural vocabulary behind cloud-based database services and clarifies why cloud scalability mechanisms differ in kind, not just degree, from those of locally hosted systems.
Together these videos build the foundation the module outcomes require. The DBaaS explainer establishes the defining infrastructure characteristics of managed cloud databases against self-hosted installations (MO1) and highlights which maintenance, backup, and security duties shift to the provider, supporting the trade-off analysis in MO4 and the shared responsibility classification in MO5. The cloud-native video clarifies elasticity and managed-service design, giving you the conceptual basis for contrasting cloud scaling with the hardware-bound scaling of local systems (MO3), while the database-selection video models the requirements-driven reasoning — including cost and growth considerations relevant to capital versus operational spending (MO2) — that you will apply when recommending a hosting strategy for a given organizational scenario.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.