Choosing a Database Platform

Build the mental model

The Cloud & Deployment course's production-data-and-storage lesson already covers the fundamentals of running a production database — backups, connection handling, basic scaling concerns. This lesson is about a narrower, later question: once you know you need a database, which platform should host it?

Path	Description
Major Cloud Managed DB	Runs a real database engine (Postgres, MySQL, etc.) with the cloud handling patching, backups, and scaling — while you keep real control over engine, version, and configuration
BaaS Built-in DB	The kind covered in this course's own Supabase and Firebase lessons — bundles a database with auth, storage, and often realtime features in one integrated product
Dedicated DB Platform	Including self-hosting the engine yourself — the most control over exactly which engine, version, and configuration you run, at the cost of managing more yourself

Choosing between these isn't about picking the "best" database technology — it's about deciding how tightly coupled to a BaaS's other features you're comfortable being, how much control you actually need over the engine and its version, what your team already knows, and how much you care about being able to migrate the data elsewhere later without a painful rewrite.

Portability matters especially here

Portability concerns and vendor lock-in — covered in the next lesson — matter especially here, since a database holds your actual data.

text

THREE PATHS TO A DATABASE
-------------------------
MAJOR CLOUD MANAGED DB
  real engine (Postgres/MySQL), cloud handles ops
  best fit: need engine/version control, existing cloud usage

BaaS BUILT-IN DB (e.g. Supabase, Firebase)
  bundled with auth, storage, realtime in one product
  best fit: speed + integration matter more than engine control

DEDICATED DB PLATFORM (managed or self-hosted)
  most control over engine, version, configuration
  best fit: specialized tuning, extensions, or full independence

Connect it to a real scenario

Consider a small team already building their app on Supabase for auth and storage. Adding Supabase's built-in Postgres database as well keeps everything in one dashboard, one billing relationship, one set of client libraries — genuinely convenient, and the natural default unless something specific argues against it.

Now consider a team running a data-heavy analytics product that needs a specific database engine version, custom extensions, and fine-grained tuning that a BaaS wrapper doesn't expose — a major cloud's managed database service, or a dedicated database platform, gives that engine-level control the BaaS doesn't.

And consider a team that expects to possibly move providers in two years and wants to minimize that pain in advance — leaning toward standard SQL, avoiding proprietary query extensions, and choosing a platform that supports standard export and connection methods reduces how painful that future migration would be, regardless of which of the three paths they pick today.

None of these three paths is the universal right answer. The question each team should actually ask is: how much do we value speed and integration right now, versus engine control, versus keeping our options open for later?

Choosing a database platform means choosing between three landscape-level paths: managed cloud DB, BaaS built-in DB, dedicated DB platform
The decision depends on coupling, engine control, team preference, and portability
No single database technology is the universal "best" choice

Try the working example

javascript

function recommendDatabasePath(situation) {
  const {
    alreadyUsingBaaS = false,
    needsFullEngineControl = false,
    needsPortability = false,
    teamPrefersSQL = false,
  } = situation;

  // Full engine control or heavy portability concerns push away from a bundled BaaS.
  if (needsFullEngineControl || needsPortability) {
    return teamPrefersSQL
      ? "major-cloud-managed-db-or-dedicated-platform (standard SQL engine)"
      : "dedicated-db-platform (maximum control over engine/version)";
  }

  // Already invested in a BaaS with no strong reason to split things apart.
  if (alreadyUsingBaaS) {
    return "baas-built-in-db (keep it bundled with auth/storage)";
  }

  // No BaaS yet, no special control/portability need: a managed cloud DB is a solid default.
  return "major-cloud-managed-db";
}

const examples = [
  { name: "Small app already on Supabase for auth", situation: { alreadyUsingBaaS: true } },
  { name: "Analytics product needing custom Postgres extensions", situation: { needsFullEngineControl: true, teamPrefersSQL: true } },
  { name: "New backend, no BaaS yet, wants standard SQL", situation: { teamPrefersSQL: true } },
];

for (const ex of examples) {
  console.log(ex.name, "->", recommendDatabasePath(ex.situation));
}

You should see

Small app already on Supabase for auth -> baas-built-in-db (keep it bundled with auth/storage)
Analytics product needing custom Postgres extensions -> major-cloud-managed-db-or-dedicated-platform (standard SQL engine)
New backend, no BaaS yet, wants standard SQL -> major-cloud-managed-db

5-minute try-it

Add needsPortability: true while alreadyUsingBaaS is also true and see what recommendation comes back — think about why it overrides the BaaS default

One important caution

Automatically choosing the built-in database just because you're already using the BaaS, without weighing other requirements

Treating SQL versus NoSQL preference as a "which is objectively better" argument instead of a real team-context factor

Wikipedia: Database-as-a-service — Cloud Providers & Platforms