DB Resources¶

You made it through 16 files of database curriculum If you actually read (and practiced) all of them, you now know more about databases than most developers who've been "working with databases for years" - because most developers learn just enough SQL to pass their CRUD endpoints and never think about indexes, query plans, security, or the tradeoff between document stores and relational models until their production database catches fire at 2AM on a Saturday

Comparison table¶

When to use each¶

PostgreSQL - your default choice for anything that needs to store data reliably with complex query patterns. Start with Postgres unless you have a specific reason not to. The JSONB column gives you document flexibility when you need it, the extension ecosystem gives you geospatial (PostGIS) and full-text search, and the query optimizer is smarter than you are - let it do its job

MongoDB - when your data is naturally document-shaped with deep nesting that would require 12 JOINs in SQL , when you need to scale writes across commodity hardware , when your schema changes every sprint during rapid product iteration , and when you can tolerate eventual consistency for most operations. Don't use MongoDB because "NoSQL is trendy" - use it because your data genuinely fits the document model better than relational

Redis - when you need SPEED measured in microseconds , when you need ephemeral data with automatic expiry , when you need atomic counters and distributed locks and pub/sub channels. Never use Redis as your primary database unless you enjoy losing data when the server restarts. Redis is a performance layer on top of a persistent database , not a replacement for one

SQLite - for development (instead of running Postgres locally) , for testing (in-memory databases that clean up automatically) , for embedded applications (desktop software, mobile apps, IoT) , for serverless functions where you can't run a database daemon. SQLite handles surprising amounts of traffic - many production sites run SQLite for months before they need to upgrade to Postgres

Official documentation links¶

• PostgreSQL: https://www.postgresql.org/docs/
• The manual is comprehensive and well-written. Read the "Performance Tips" chapter and "Indexes" chapter at minimum
• https://www.postgresql.org/docs/current/indexes.html - Index types and usage

• https://www.postgresql.org/docs/current/sql-explain.html - EXPLAIN documentation

• MongoDB: https://www.mongodb.com/docs/

• https://www.mongodb.com/docs/manual/aggregation/ - Aggregation pipeline reference
• https://www.mongodb.com/docs/manual/indexes/ - Indexing strategies

• https://www.mongodb.com/docs/manual/security/ - Security checklist

• Redis: https://redis.io/docs/

• https://redis.io/docs/data-types/ - Data type overview
• https://redis.io/docs/management/security/ - Security guide

• https://redis.io/docs/management/persistence/ - RDB and AOF persistence

• SQLite: https://www.sqlite.org/docs.html

• https://www.sqlite.org/wal.html - WAL mode documentation

• https://www.sqlite.org/lang.html - SQL syntax reference

• Prisma: https://www.prisma.io/docs

• https://www.prisma.io/docs/concepts/components/prisma-schema - Schema reference
• https://www.prisma.io/docs/concepts/components/prisma-client - Client API

Recommended books¶

PostgreSQL: * "PostgreSQL: Up and Running" by Regina Obe - best practical intro , gets you productive fast with real examples * "The Art of PostgreSQL" by Dimitri Fontaine - advanced query techniques that make you think in set operations instead of procedural loops

MongoDB: * "MongoDB: The Definitive Guide" by Shannon Bradshaw - the official guide covering everything from basics to sharding * "NoSQL Distilled" by Martin Fowler - not MongoDB-specific but the best conceptual overview of NoSQL paradigms

Redis: * "Redis in Action" by Josiah L. Carlson - practical patterns for caching , sessions , analytics , and pub/sub

SQLite: * "Using SQLite" by Jay A. Kreibich - the definitive reference , though most of what you need is in the docs

Database Theory: * "Designing Data-Intensive Applications" by Martin Kleppmann - this isn't about any specific database but about the fundamental concepts behind them. If you only read one book about data , read this one. It explains why databases work the way they do, what tradeoffs they make, and how to think about distributed systems problems

Recommended courses and resources¶

• Use the Index, Luke (https://use-the-index-luke.com/) - the single best resource for understanding database indexing regardless of which database you're using. Free, practical, and immediately applicable

• PG Casts (https://www.pgexercises.com/) - free Postgres exercises that run in your browser. No setup needed , just solve SQL problems

• Redis University (https://university.redis.com/) - free courses from Redis Labs covering Redis basics, data structures, and clustering

• Prisma's Documentation has excellent examples - their guides on relations, migrations, and advanced queries are better than most paid courses

• SQL Fiddle / DB Fiddle - online tools for testing SQL queries without setting up a database

Final advice from someone who's broken more databases than you've created¶

Backups are not optional until you've lost production data once - and after you've lost production data once , you'll never skip backups again. Test your backups by actually restoring them to a test environment

The most expensive lesson in database engineering:

"I didn't think that query would lock the whole table"
"I didn't know ALTER TABLE ADD COLUMN blocks reads in Postgres"
"I thought the migration would take 2 seconds not 30 minutes"
"I forgot the WHERE clause in UPDATE"
"I didn't need an index because the table is small"

Every single one of these has caused production incidents. The databases don't care about your feelings. They execute what you tell them to execute, and if you tell them to scan 10 million rows sequentially or to update every row in a table without a WHERE clause, they will do exactly that - with enthusiasm

Next steps¶

Go build something that uses at least two of these databases together - a Node.js app with Postgres for persistent data and Redis for caching , or a mobile app with SQLite for offline storage and MongoDB for cloud sync. The theory is worthless without implementation

← back to db_00_home.md