Seven Databases in Seven Weeks - A Guide to Modern Database Systems

Introduction

Ever wondered why there are so many different databases, and which one you should actually use for your Java Spring Boot project? I’ve been there too, staring at a list of database options feeling completely overwhelmed. The truth is, understanding these seven databases in seven weeks isn’t just about memorizing features, it’s about learning when each tool shines and when it falls short. Let me walk you through each one, sharing what I’ve learned from building real applications and making plenty of mistakes along the way.

Understanding the Seven Databases Paradigms

Before we dive into the seven databases, let’s talk about why we even need different types. Think of databases like tools in a toolbox. You wouldn’t use a hammer to screw in a bolt, right? Similarly, each database is optimized for specific patterns and use cases.

When I first started with Spring Boot, I defaulted to PostgreSQL for everything. It worked, but I quickly learned that wasn’t always the best choice. Some problems need the speed of Redis, others need the flexibility of MongoDB, and some need the relationship power of Neo4j. Understanding these paradigms will make you a better architect and help you make informed decisions.

1. PostgreSQL - The Relational Powerhouse

PostgreSQL is the reliable, battle-tested relational database that’s been evolving for over 30 years. It excels at structured data with relationships, ACID transactions, and complex queries.

📓 School Binder (PostgreSQL):
Students Table:
┌────┬──────────┬─────┬────────┐
│ ID │ Name     │ Age │ Grade  │
├────┼──────────┼─────┼────────┤
│ 1  │ Alice    │ 10  │ 5      │
│ 2  │ Bob      │ 11  │ 5      │
│ 3  │ Charlie  │ 10  │ 5      │
└────┴──────────┴─────┴────────┘
Homework Table:
┌────┬────────────┬───────────┬───────┐
│ ID │ Student_ID │ Subject   │ Grade │
├────┼────────────┼───────────┼───────┤
│ 1  │ 1          │ Math      │ A     │
│ 2  │ 1          │ Science   │ B+    │
│ 3  │ 2          │ Math      │ A-    │
└────┴────────────┴───────────┴───────┘
✅ Everything is organized perfectly!

When to Use PostgreSQL

Use PostgreSQL when:

• You need ACID transactions for financial data, user accounts, or anything where consistency is critical
• Your data has clear relationships (users → orders → items)
• You require complex queries with joins, aggregations, and window functions
• You need strong consistency guarantees

Avoid PostgreSQL when:

• You need horizontal scaling across many nodes
• Your data is highly unstructured and changes frequently
• Your queries are simple key-value lookups (Redis would be faster)

2. Redis - The In-Memory Speed Demon

Redis is an in-memory data structure store that delivers sub-millisecond response times. It’s perfect for caching, session storage, and real-time features.

📦 Your Desk Drawer (Redis):
┌─────────────────────────────┐
│ Key          → Value         │
├─────────────────────────────┤
│ “favorite_color” → “blue”   │
│ “high_score”     → 9999     │
│ “friends_list”   → [👧👦👨] │
│ “game_level”     → 42       │
└─────────────────────────────┘
⚡ Super fast to grab!
⚠️  But lives in memory (RAM)

When to Use Redis

Use Redis when:

• You need sub-millisecond latency for data access
• You’re building a caching layer to reduce load on your main database
• You need session storage for web applications
• You want real-time features like leaderboards, counters, or rate limiting

Avoid Redis when:

• You need persistent storage as your primary database
• Your dataset is too large for memory
• You need complex queries or relationships between data
• You require ACID transactions across multiple keys

3. MongoDB - The Document Store Pioneer

MongoDB is a NoSQL document database that stores data in flexible, JSON-like documents. It’s schema-less, meaning documents in the same collection can have completely different structures.

📇 Pokemon Cards Collection (MongoDB):
Card 1: {
name: “Pikachu”,
type: “Electric”,
level: 25,
moves: [“Thunder”, “Quick Attack”]
}
Card 2: {
name: “Charizard”,
type: “Fire”,
level: 36,
moves: [“Flamethrower”, “Fly”],
evolution_from: “Charmeleon”,
rare: true
}
Card 3: {
name: “Bulbasaur”,
type: “Grass”,
level: 10
}
✨ Each card can be different!

When to Use MongoDB

Use MongoDB when:

• Your data is document-oriented and semi-structured (user profiles, product catalogs)
• You need rapid schema evolution without running migrations constantly
• You’re building content management systems or applications where data structure varies
• You need horizontal scaling for large datasets
• Your queries are mostly single-document operations

Avoid MongoDB when:

• You need complex joins across collections
• You require ACID transactions across multiple documents
• Your data has strict relational integrity requirements
• You need complex analytical queries with lots of aggregations

4. CouchDB - The Distributed Document Database

CouchDB is a document-oriented NoSQL database designed for offline-first applications and distributed systems. It uses JSON for documents, JavaScript for MapReduce queries, and HTTP for its API.

📓 Syncing Notebooks (CouchDB):
Your Notebook (Offline):        Friend’s Notebook:
┌──────────────────┐           ┌──────────────────┐
│ Entry 1: …     │           │ Entry 1: …     │
│ Entry 2: NEW!    │           │ Entry 3: NEW!    │
└──────────────────┘           └──────────────────┘
│                              │
└──────────────┬───────────────┘
│
When Online
↓
┌──────────────────┐
│ Entry 1: …     │
│ Entry 2: NEW!    │
│ Entry 3: NEW!    │
└──────────────────┘
🔄 Syncs automatically!

When to Use CouchDB

Use CouchDB when:

• You need offline-first applications, especially mobile apps that need to work without internet
• You require master-master replication across data centers
• You’re building sync-enabled applications, like note-taking apps or collaborative tools
• You want a RESTful API without needing custom drivers

Avoid CouchDB when:

• You need strong consistency guarantees (CouchDB is eventually consistent)
• You require complex queries or aggregations
• You need high write throughput
• You need real-time queries

5. Neo4j - The Graph Database

Neo4j is a native graph database that stores data in nodes (entities) and relationships (edges). It’s optimized for traversing relationships and understanding connections in your data.

🕸️ Friendship Web (Neo4j):
(You) 👦
/ | 

/  |  

👧  👨  👩
|    |    |
|    |    |
👦  👧  👨
\   |   /
\  |  /
\ | /
👧
Connections matter more than the people!
Can answer: “Who are my friend’s friends?”

When to Use Neo4j

Use Neo4j when:

• Your data is highly connected, like social networks, knowledge graphs, or organizational charts
• You need to traverse relationships frequently (finding paths, degrees of separation)
• You’re building recommendation engines (friend suggestions, product recommendations)
• You need fraud detection or pattern matching based on connections
• You need graph algorithms (shortest path, centrality, clustering)

Avoid Neo4j when:

• Your data is mostly disconnected (simple CRUD operations)
• You need complex aggregations or analytical queries
• Your relationships are simple and few (PostgreSQL handles that fine)
• You need high write throughput for simple operations

6. HBase - The Columnar Big Data Store

HBase is a distributed, scalable, big data store modeled after Google’s Bigtable. It’s built on top of Hadoop and provides random, real-time read/write access to large datasets.

🏢 Giant Warehouse Library (HBase):
Warehouse Section A (Robot 1):
Row: user_001 → [posts: 1000, likes: 5000]
Row: user_002 → [posts: 50, likes: 200]
Warehouse Section B (Robot 2):
Row: user_999 → [posts: 2000, likes: 8000]
Row: user_1000 → [posts: 100, likes: 500]
Warehouse Section C (Robot 3):
Row: user_5000 → [posts: 500, likes: 1000]
🤖 Each robot handles millions of rows!
📦 Billions of total items possible!

When to Use HBase

Use HBase when:

• You have massive datasets (billions of rows, petabytes of data)
• You need horizontal scaling across hundreds of nodes
• You’re storing time-series data like IoT sensor readings, application logs, or metrics
• Your data is sparse (many possible columns, but few populated per row)
• You need high write throughput (millions of writes per second)

Avoid HBase when:

• Your dataset is small to medium (PostgreSQL or MongoDB will be simpler and faster)
• You need ACID transactions across multiple rows
• You require complex queries or joins
• Your team lacks Hadoop/HBase expertise

7. Riak - The Distributed Key-Value Store

Riak is a distributed NoSQL key-value database designed for high availability, fault tolerance, and operational simplicity. It’s inspired by Amazon’s Dynamo paper and focuses on eventual consistency.

🔄 Team of Filing Cabinets (Riak):
Cabinet A (NYC):          Cabinet B (London):      Cabinet C (Tokyo):
┌─────────────┐          ┌─────────────┐          ┌─────────────┐
│ key: user1  │          │ key: user1  │          │ key: user2  │
│ key: user2  │          │ key: user3  │          │ key: user3  │
│ key: user3  │          │ key: user4  │          │ key: user4  │
└─────────────┘          └─────────────┘          └─────────────┘
│                         │                         │
└─────────────────────────┴─────────────────────────┘
All connected & synced!
✅ If one breaks, others keep working!
✅ Add/remove cabinets anytime!
✅ Copies everywhere = super safe!

When to Use Riak

Use Riak when:

• You need high availability and fault tolerance (system keeps running even with node failures)
• You’re building distributed systems across multiple data centers
• You need simple key-value operations at scale
• You want operational simplicity (adding/removing nodes is straightforward)
• You can tolerate eventual consistency

Avoid Riak when:

• You need strong consistency guarantees (Riak prioritizes availability)
• You require complex queries or relationships
• You need ACID transactions
• Your use case is simple caching (Redis is faster for that)

🎯 Quick Pick Guide

Best Practices for Database Selection

After working with all these databases, I’ve learned some hard lessons about choosing the right one. Here are my best practices:

Start with Your Requirements, Not the Database

I’ve made the mistake of choosing a database because it was trendy or because I wanted to learn it. Don’t do that. Start by understanding your data access patterns, consistency requirements, scale expectations, and team expertise.

Consider the Team’s Expertise

If your team is comfortable with SQL and relational thinking, PostgreSQL might be a better choice than MongoDB, even if MongoDB could technically work. The learning curve and operational complexity matter.

Think About Operations

Some databases are easier to operate than others. PostgreSQL and MongoDB have great tooling and large communities. HBase and Riak require more specialized knowledge. Consider who will be on-call at 3 AM when something breaks.

Plan for Growth, But Don’t Over-Engineer

I’ve seen teams choose HBase for applications that would never exceed a few million rows. Start simple with PostgreSQL or MongoDB, and add specialized databases when you actually need them. Premature optimization is still the root of all evil.

Use Multiple Databases (Polyglot Persistence)

Most real-world applications use multiple databases. Your Spring Boot app might use PostgreSQL for transactional data, Redis for caching, MongoDB for content, and Elasticsearch for search. This is normal and often the right approach.

Test Your Assumptions

Before committing to a database, build a proof of concept. Test it with realistic data volumes and access patterns. What looks good on paper might not work in practice.

Common Mistakes and Pitfalls

I’ve made plenty of mistakes with databases over the years. Here are the most common ones I see:

Mistake 1: Choosing a Database for the Wrong Reasons

Don’t choose MongoDB because it’s “modern” or PostgreSQL because it’s “safe.” Choose based on your actual requirements. I’ve seen teams struggle with MongoDB when they really needed relational integrity, or use PostgreSQL when they needed the speed of Redis.

Mistake 2: Ignoring Consistency Requirements

Understanding CAP theorem (Consistency, Availability, Partition tolerance) is crucial. If you need strong consistency, eventual consistency databases like Riak or CouchDB won’t work. If you need high availability, strongly consistent databases might not scale the way you need.

Mistake 3: Not Planning for Scale

I’ve seen applications start with PostgreSQL, grow to millions of users, and then struggle to scale. While you shouldn’t over-engineer, you should understand the scaling path. Can your chosen database scale horizontally? What does that process look like?

Mistake 4: Underestimating Operational Complexity

HBase requires Hadoop expertise. Neo4j requires understanding graph algorithms. Even MongoDB has operational complexities around sharding and replication. Make sure your team can actually operate the database you choose.

Mistake 5: Not Considering the Ecosystem

PostgreSQL has incredible Spring Boot integration via Spring Data JPA. MongoDB has Spring Data MongoDB. But some databases have less mature integrations. Consider how well your chosen database integrates with your tech stack.

Mistake 6: Forgetting About Data Modeling

Each database requires different data modeling approaches. Relational databases need normalization. Document databases benefit from denormalization. Graph databases think in terms of relationships. Don’t try to force one model onto another.

Frequently Asked Questions

1. Should I use PostgreSQL or MongoDB for my Spring Boot application?

This depends on your data structure. If you have clear relationships between entities (users, orders, products) and need ACID transactions, PostgreSQL is usually the better choice. If your data is document-oriented, changes frequently, and you need horizontal scaling, MongoDB might be better. For most Spring Boot applications starting out, I’d recommend PostgreSQL unless you have a specific reason not to.

2. When should I add Redis to my application?

Add Redis when you need sub-millisecond response times, want to reduce load on your main database, or need features like session storage, rate limiting, or pub/sub messaging. I usually add Redis as a caching layer once my application starts seeing real traffic and I notice database queries becoming a bottleneck.

3. Can I use multiple databases in the same application?

Absolutely! This is called polyglot persistence, and it’s common in modern applications. You might use PostgreSQL for transactional data, Redis for caching, MongoDB for content, and Elasticsearch for search. Spring Boot makes this easy with different Spring Data modules.

4. How do I choose between Neo4j and a relational database for relationship data?

If your relationships are simple (like foreign keys), a relational database is probably sufficient. But if you need to traverse relationships frequently (finding paths, degrees of separation, complex relationship queries), Neo4j will be much faster. Think about your query patterns: if you’re asking “who are my friends’ friends?” often, Neo4j is worth considering.

5. Is it worth learning all seven databases?

You don’t need to master all of them, but understanding the different paradigms (relational, document, key-value, graph, columnar) will make you a better architect. I’d recommend getting comfortable with PostgreSQL and Redis first, then learning MongoDB. The others (CouchDB, Neo4j, HBase, Riak) are more specialized, so learn them when you have a specific need.

Alternatives and When to Consider Them

While we’ve covered seven databases, there are many alternatives worth knowing about:

For Relational Data

• MySQL: Similar to PostgreSQL, very popular, great for web applications
• SQL Server: Microsoft’s database, excellent if you’re in a Microsoft ecosystem
• Oracle: Enterprise-grade, but expensive and complex

For Caching

• Memcached: Simpler than Redis, but less feature-rich
• Hazelcast: In-memory data grid, great for Java applications

For Document Storage

• Amazon DynamoDB: Managed NoSQL database, great if you’re on AWS
• Couchbase: Similar to CouchDB but with better performance characteristics

For Graph Data

• Amazon Neptune: Managed graph database on AWS
• ArangoDB: Multi-model database supporting graphs, documents, and key-value

For Big Data

• Cassandra: Similar to HBase but optimized for low-latency reads
• Google Bigtable: The inspiration for HBase, available on Google Cloud
• Amazon Redshift: Data warehouse, great for analytics

The key is understanding when these alternatives might be better fits. For example, if you’re already on AWS, DynamoDB might be easier than managing your own MongoDB cluster.

Conclusion

Exploring these seven databases has taught me that there’s no one-size-fits-all solution. Each database is a tool optimized for specific problems. PostgreSQL excels at relational data with ACID guarantees. Redis delivers sub-millisecond performance for caching and real-time features. MongoDB offers flexibility for evolving schemas. CouchDB handles offline-first and distributed scenarios. Neo4j traverses relationships like no other. HBase scales to petabytes. Riak prioritizes availability and fault tolerance.

As a Java Spring Boot developer, you’ll likely use PostgreSQL and Redis in most projects, with MongoDB for specific use cases. The others are specialized tools you’ll reach for when you have specific requirements.

The most important lesson? Start simple, understand your requirements, and add specialized databases when you actually need them. Don’t let the perfect be the enemy of the good. You can always evolve your architecture as your needs change.

Ready to dive deeper? Check out the Spring Boot Master Class for hands-on experience building real-world applications with these databases. You’ll learn not just how to use them, but when to use them, and that’s the real skill that separates good developers from great architects.