All Playbooks
Databaseintermediate

Choosing a Database in 2026

Database choice is one of the highest-cost, hardest-to-reverse technical decisions in a product. This playbook is the decision framework I walk teams through when they ask me to weigh in: define the workload first, pick a sensible default, evaluate hosted options on real criteria, plan for scale before you need it, prototype the hardest query, and document the choice so the next engineer does not have to relitigate it.

60 min7 steps
7

Steps

5

Tools

5

Outcomes

intermediate

Difficulty

Technologies used

PostgreSQLMongoDBDynamoDBTursoNeon

The methodology

The phases, in order

Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.

01

Phase

Phase 1 of 7

Define the Workload

I write down read/write ratio, data shape, query complexity, expected size in a year, and latency targets. Most database mistakes start as workload mistakes: optimizing for a write-heavy system that is actually read-heavy, or paying for a fast database to serve queries that could be cached.
02

Phase

Phase 2 of 7

Pick a Sensible Default

For most products the answer is Postgres. It has the broadest tooling, the richest type system, and a community that has solved most of the problems you will hit. Going against the default needs an explicit reason like ultra-low-latency global reads or schemaless workloads. See Postgres vs MongoDB for the head-to-head.
03

Phase

Phase 3 of 7

Evaluate Hosted Options

Once the engine is chosen, I shop the hosted options on three axes: developer ergonomics, regional coverage, and price at scale. Neon and Supabase win on ergonomics. RDS wins on flexibility. Turso wins on edge latency. Reference Supabase vs Firebase for a related comparison.
04

Phase

Phase 4 of 7

Plan for Scale Early

I sketch the index strategy, the partitioning scheme, and the read replica plan before the first deploy. Even if I do not implement them yet, knowing the plan lets me avoid choices that lock the system out of those options later. Adding a primary key after the fact on a hot table is a special kind of pain.
05

Phase

Phase 5 of 7

Prototype the Hardest Query

I run the single hardest query I expect to need against realistic data volume, on the hosted plan I am considering. Most databases are great on toy data and surprising at production scale. A 30-minute prototype here saves a 30-day migration later.
06

Phase

Phase 6 of 7

Pick the ORM Carefully

The ORM matters almost as much as the database. Prisma optimizes for developer ergonomics, Drizzle optimizes for type safety and SQL closeness. See Prisma vs Drizzle. For very high-performance workloads I sometimes skip the ORM and write SQL directly with type-safe wrappers.
07

Phase

Phase 7 of 7

Document the Decision

I capture the rationale in an architecture decision record: what we chose, what we considered, what we rejected, and what would change our minds. ADRs save the team from relitigating every choice when a new engineer joins, and they are honest record of why the system looks the way it does.

Results

What You'll Achieve

Expected outcomes from implementing this playbook

A defensible database choice with written rationale
A migration plan if you outgrow the initial choice
Confidence in the scaling profile before going live
A clear ORM selection that fits the team
Need an architecture session? Start a project.

Use this playbook

Want me to run this with you?

The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.

Start a projectJust ask a question

Next up

Hiring · 90 min

Hiring Your First Engineer

Your first engineering hire shapes the next two years of the company more than almost any product decision. Most founders rush this and pay for it for a long time. This playbook is the hiring loop I recommend: scope the role honestly, source where engineers actually live, design a realistic interview, check references hard, and onboard with a real plan rather than a vague mandate.

Database

Related Playbooks

Other playbooks in this category

intermediate

Building Real-time Features with Supabase

Real-time features sell products, but they also break in spectacular ways if you do not respect the limits of the underlying broker. This playbook is how I add live subscriptions, presence, and optimistic updates to a React app using Supabase, without ending up with a UI that flickers on every reconnection. It covers schema design, RLS, presence, and the patterns that keep real-time work feeling instant rather than fragile.

advanced

Managing Database Migrations

Database migrations are the part of the system where a tiny mistake creates an outage that lasts hours. This is the playbook I follow when migrating a production schema: expand-then-contract, dual writes when needed, idempotent scripts, a real rollback plan, and verification that does not depend on the migration tool reporting success. Boring on purpose, because exciting migrations are the dangerous ones.

advanced

Multi-Tenant SaaS Architecture

Multi-tenancy is one of the highest-leverage architectural decisions in a SaaS, and almost impossible to fix later. This playbook is the model I use to design tenant isolation that scales from ten customers to ten thousand: shared schema with row-level isolation, tenant-scoped routing, configuration, billing, and an admin layer that lets you operate the platform without breaking customer trust.

Previous

Migrating a Monolith to Microservices

Next

Hiring Your First Engineer