Why this is in the vault
Part 2 of Technically's "Software Eng for Vibe Coders" series walks non-engineers through databases, schemas, migrations, and object storage using a running fictional case (Art Vandelay's potato-chip supplier app) — worth keeping as a plain-language artifact for explaining why AI-provisioned databases fail under real load.
The core argument
Coding agents quietly pick a database (usually Postgres, hosted on Railway/Supabase/Neon) and a schema on the founder's behalf, and most of the failure modes that "ruin a launch" trace back to decisions nobody reviewed. The piece walks through: schemas as the enforced rulebook for what data a column accepts; normalization/relations (splitting data into linked tables via foreign keys) so updates don't require hunting down duplicates; ACID guarantees that stop two simultaneous orders from selling the same inventory; connection pooling to avoid "too many connections" crashes when serverless functions each grab a slot; indexes as the fix for pages that are fast at 100 rows and dead at a million; and migrations as version-controlled, reviewable schema changes rather than live hand-edits. It closes on object storage: large files (images, PDFs) belong outside the database entirely, in something like S3, with the database holding only a pointer.
The piece is explicit that most of this is invisible until scale hits — "it was never slow — it just never had enough data to be slow, until one day it did" — and that AI-generated migrations deserve skepticism since "just adding a column" can silently become a dropped table.
Mapping against Ray Data Co
This is a checklist against MAC and Squarely's own provisioned databases: RDCO should be able to answer, without guessing, whether indexes exist on the columns actually queried/joined, whether a connection pooler is on, and whether migrations are reviewed files rather than live edits — the same three items the piece flags as the ones vibe-coded apps skip until they break in production. It's also a reminder that "the coding agent set up a database for you" is a decision, not a non-decision, and merits an explicit review pass before any surface takes real traffic.
Related
- [[2026-08-11-technically-frontend-backend-vibe-coders]]
- [[2026-07-14-practical-data-modeling-database-is-not-data-model]]
- [[feedback_no_autonomous_external_email]]
⚠️ Sponsorship
Railway sponsors this entire 6-part "Software Eng for Vibe Coders" series (same sponsor as Part 1, 2026-08-11). The issue names Railway twice with referral-tagged links and frames it as the tool that "helps you peacefully deploy vibe coded apps." Bias implication: the piece's comparison of Railway/Supabase/Neon reads even-handed and technically accurate, but Railway gets the framing edge (listed first, described as "all-in-one") and the call-to-action link. Treat the provider comparison as directionally useful, not neutral.