Back to Playbook

Database Playbook

Your app needs to remember things. But which database

Database

An organized collection of structured information, or data, typically stored electronically in a computer system.

"Like a giant, super-organized filing cabinet where the app stores all its users, posts, and details."

should you use? SQL

SQL (Structured Query Language)

A programming language used to communicate with relational databases. Data is stored in tables with rows and columns.

"Like an Excel spreadsheet. Very structured, strict rules, great for consistent data."

? NoSQL

NoSQL

Databases that store data in a format other than relational tables, often as documents (JSON-like). Flexible and scalable.

"Like a folder of word documents. You can throw any kind of info into a doc; they don't all have to look the same."

? Firebase? Neon

Neon

Serverless PostgreSQL. A modern database that auto-scales, branches like Git, and has a generous free tier. Perfect for vibe coding.

"Like PostgreSQL that wakes up when you need it and sleeps when you don't. Pay for what you use."

? Here's how to choose — and avoid the pitfalls.

1The Big Picture

A database is where your app stores data — users, posts, orders, anything that needs to persist. But not all databases are created equal. The right choice depends on your data shape, scale, and how you query it.

The Two Big Categories

SQL (Relational)

Data lives in tables with rows and columns. Relationships are strict. Great for structured data.

PostgreSQL, MySQL, SQLite

NoSQL (Non-Relational)

Data stored as documents, key-value pairs, or graphs. Flexible schema. Great for unstructured data.

MongoDB, Firebase, Redis, DynamoDB

2When Each Database Shines

PostgreSQL

The Swiss Army knife. Does everything well.

Best For

  • • Complex queries and joins
  • • Financial data / transactions
  • • Apps with clear data relationships
  • • When you need ACID compliance

Example Use Cases

  • • E-commerce (orders, users, products)
  • • SaaS applications
  • • Any Next.js / Vercel project
  • • CMS and dashboards

Vibe Coder Take: When in doubt, use Postgres. It handles 90% of use cases and scales further than you think.

MongoDB

Document database. JSON-like storage.

Best For

  • • Rapidly changing schemas
  • • Nested/hierarchical data
  • • Content management systems
  • • Prototyping and MVPs

Example Use Cases

  • • Blog platforms with varied post types
  • • Product catalogs with different attributes
  • • Real-time analytics
  • • IoT data logging

When to pick over Postgres: Your data doesn't fit neatly into tables, or each record has wildly different fields.

Firebase / Firestore

Google's real-time database with built-in auth.

Best For

  • • Real-time sync (chat, live updates)
  • • Mobile apps (iOS, Android, Flutter)
  • • Quick MVPs with auth included
  • • Offline-first applications

Example Use Cases

  • • Chat applications
  • • Collaborative tools (like Figma)
  • • Mobile games with leaderboards
  • • Social apps

When to pick over Postgres: You need real-time sync out of the box, or you're building mobile-first and want auth + DB in one SDK.

Redis

In-memory key-value store. Blazing fast.

Best For

  • • Caching (speed up slow queries)
  • • Session storage
  • • Rate limiting
  • • Real-time leaderboards

Example Use Cases

  • • API response caching
  • • User session management
  • • Job queues (with BullMQ)
  • • Pub/sub messaging

Key insight: Redis is usually paired with a primary database, not a replacement. Use it for speed; use Postgres for durability.

SQLite

Embedded database. Lives in a single file.

Best For

  • • Local-first apps
  • • Electron / desktop apps
  • • Prototyping before production
  • • Edge computing (with Turso)

Example Use Cases

  • • Mobile apps with local storage
  • • CLI tools that need persistence
  • • Browser extensions
  • • Serverless at the edge (Turso, Cloudflare D1)

Modern twist: Services like Turso and Cloudflare D1 let you run SQLite at the edge, globally replicated. Surprisingly powerful.

3Where Neon Fits In

Neon = Serverless PostgreSQL

Neon gives you the power of PostgreSQL without managing servers. It's fully managed, scales to zero when idle, and has instant branching for dev workflows.

Scale to Zero

Pauses when idle. Pay only for what you use.

Branching

Create DB branches like Git branches.

Instant Start

Wakes up in ~500ms. No cold start pain.

When to Choose Neon

  • Next.js + Vercel projects — Native integration, preview branches per PR
  • Side projects / MVPs — Generous free tier, no server management
  • Teams that want dev/staging branches — Clone your DB for testing
  • Cost-conscious apps — Scale-to-zero means $0 when not in use

4Neon vs Supabase vs PlanetScale

All three are modern, developer-friendly databases. Here's how to choose:

Neon

Pure PostgreSQL + serverless + branching. Minimalist.

Best for: Vercel projects, cost-sensitive apps, teams that want DB branching.

Supabase

PostgreSQL + Auth + Storage + Realtime + Edge Functions. All-in-one.

Best for: Full-stack apps that need auth, MVPs, teams that don't want to stitch services together.

PlanetScale

MySQL-compatible with Vitess. Horizontal scaling, schema branching.

Best for: High-scale apps, teams comfortable with MySQL, complex migrations.

Our Take: If you just need a database → Neon. If you need auth + DB + storage in one → Supabase. If you need MySQL or massive scale → PlanetScale.

5Framework Pairings

Different frameworks have natural database partners:

Next.js
Neon or Supabase

Both have first-class Vercel integrations

React Native
Firebase or Supabase

Real-time sync, offline support, built-in auth

Flutter
Firebase

Native Dart SDK, real-time listeners

Remix / Nuxt
Neon + Drizzle/Prisma

Server-side rendering loves PostgreSQL

Electron
SQLite

Embedded, no server needed, ships with your app

6Common Pitfalls (And How to Avoid Them)

Picking NoSQL because "it's easier"

MongoDB feels easy at first — no schema! But when your app grows, you'll miss joins and constraints. Most apps have relational data.

Fix: Start with Postgres. It's not harder — just different. ORMs like Drizzle make it feel like working with objects.

Using production DB for development

One wrong DELETE and your real users are affected. Testing migrations on production is how outages happen.

Fix: Use Neon's branching. Create a dev branch that mirrors production. Test there. Merge when ready.

Forgetting about connection limits

Serverless functions spawn many instances. Each opens a DB connection. You hit the limit and everything breaks.

Fix: Use a connection pooler. Neon has built-in pooling. For others, use PgBouncer or Prisma's connection pooling.

Not using an ORM (or using one wrong)

Raw SQL strings are error-prone and hard to maintain. But heavy ORMs can hide what's actually happening.

Fix: Use a lightweight ORM like Drizzle. You get TypeScript safety without the magic. You can still see/write SQL when needed.

Storing env vars wrong

Committing DATABASE_URL to GitHub. Using the same credentials for dev and prod. Not rotating keys.

Fix: Use .env.local for local dev (gitignored). Use Vercel's environment variables for production. Different credentials for each.

7Quick Setup: Neon + Drizzle

The Vibe Coding Stack

Neon + Drizzle is our recommended combo. Type-safe queries, auto-generated migrations, serverless-ready.

1. Install packages:

npm install drizzle-orm @neondatabase/serverless

npm install -D drizzle-kit

2. Add to .env.local:

DATABASE_URL="postgres://user:pass@ep-xxx.us-east-2.aws.neon.tech/neondb?sslmode=require"

3. Define your schema (db/schema.ts):

import { pgTable, serial, text, timestamp } from 'drizzle-orm/pg-core';


export const users = pgTable('users', {

id: serial('id').primaryKey(),

email: text('email').unique().notNull(),

name: text('name'),

createdAt: timestamp('created_at').defaultNow(),

});

4. Push schema to Neon:

npx drizzle-kit push

Ready to build?

Create a free Neon database and connect it to your Vercel project.

Start on Neon Vercel Playbook