Shipping SQL to production means backups, least-privilege users, migration discipline, monitoring slow queries, and never testing destructive statements on live data.
Before deploy
- Reviewed migrations with rollback plan
- Indexes on FK and frequent WHERE columns
- Parameterized queries everywhere user input appears
- Separate roles: app user vs migration admin vs read-only analytics
- Backups tested with restore drill
Runtime habits
-- Bad in production console:
DELETE FROM orders;
-- Safer: transaction + preview
BEGIN;
SELECT COUNT(*) FROM orders WHERE status = 'test';
DELETE FROM orders WHERE status = 'test';
-- COMMIT; or ROLLBACK;Use query timeouts, connection pool limits, and slow-query logs. ORM debug logging off in prod.
What's next
Deepen dialect skills on PostgreSQL or MySQL. Connect SQL to apps via Django, PHP, or Python. Analytics learners continue into Data Science.
Important interview questions and answers
- Q: Why least-privilege DB user?
A: Limits blast radius if app compromised—no DROP SCHEMA from app role. - Q: Backup without restore test?
A: Untested backups are wishful thinking—schedule restore drills.
Self-check
- Name three items on the production SQL checklist.
- What should you run before DELETE in production?
Tip: Capstone: backups tested, least-privilege roles, parameterized queries, reviewed migrations. Next: dialect or app track.
Interview prep
- Least privilege?
App DB user lacks DROP and superuser rights.
- Before DELETE in prod?
SELECT count with same WHERE inside a transaction.