Por que escolhi Neon Postgres

Quando comecei a pensar em banco de dados para o site, considerei Supabase, PlanetScale, Railway, RDS e Neon. Neon ganhou — mas não por ser o "melhor Postgres do mundo", e sim porque branching de banco combina perfeitamente com preview de deploy.

O problema clássico de dev contra prod

Todo dev já passou por isso: roda pnpm dev sem perceber que a DATABASE_URL aponta pra prod, o auto-migrate do ORM roda, e agora tem 30 minutos pra reverter antes do cliente perceber. Com branch de banco, isso vira um não-problema: sua branch dev aponta para uma cópia isolada. Pode bagunçar à vontade.

Setup que funcionou aqui

Tenho três branches no Neon: main (produção), dev (a que uso localmente), e preview/* (criadas automaticamente pelo Vercel para cada PR). Cada uma com seu connection string isolado. A Vercel injeta o DATABASE_URL certo em cada ambiente.

Snippet: o helper que uso pra checar o estado do banco

1import pg from 'pg'
2
3const client = new pg.Client({ connectionString: process.env.POSTGRES_URL })
4await client.connect()
5
6const migrations = await client.query(`
7  SELECT id, name, batch, created_at
8  FROM payload_migrations
9  ORDER BY id
10`)
11
12console.table(migrations.rows)
13
14const tables = await client.query(`
15  SELECT COUNT(*)::int as total
16  FROM information_schema.tables
17  WHERE table_schema = 'public'
18`)
19console.log('Total de tabelas no schema public:', tables.rows[0].total)
Copy

Rodo isso sempre antes de mexer no banco. Se aparecer uma linha com batch = -1, sei que alguém rodou dev contra esse banco — preciso corrigir antes de qualquer deploy.

O que eu gostaria que tivessem me avisado antes

O pool de conexões do Neon é limitado em projetos free — o connection pooler (o endpoint -pooler no hostname) é obrigatório em serverless, senão você estour o limite de conexões em produção rapidamente. Payload resolve isso automaticamente quando você usa vercelPostgresAdapter com a URL pooler.

Imagem ilustrativa de exemplo. Substitua no admin em Mídia.