The Modern Database Landscape

In Lesson 18, you learned what databases are and why every application needs one. In Lesson 19, you explored how data gets organized with SQL and relational concepts. In Lesson 20, you saw the legacy databases — Oracle, DB2, SQL Server — that still power much of the world's critical infrastructure. Now it is time to look forward. Welcome to the modern database landscape.

Here is the single most important thing this lesson will teach you: there is no "best" database. Every database is a tool designed for a particular kind of job. A hammer is not better than a screwdriver — they solve different problems. MySQL is not better than MongoDB. PostgreSQL is not better than Redis. The skill that separates good developers from great ones is knowing which tool to reach for when you are staring at a new project.

By the end of this lesson, you will have a clear mental map of the modern database world. You will know what the major players are, what they are good at, who uses them, and — most importantly — how to choose the right one. Let us get started.

1. MySQL — The Reliable Workhorse

If databases had a popularity contest, MySQL would win it. MySQL is the most popular open-source database in the world. It has been around since 1995, and it powers an enormous portion of the internet. Every time you visit a WordPress blog, browse a Shopify store, scroll through Facebook, or book a ticket on Booking.com, there is a MySQL database working behind the scenes.

MySQL is a relational database, which means it uses the tables, rows, columns, and SQL language you learned about in Lessons 18 and 19. You create tables with defined columns, you insert rows of data, and you query that data using SQL. If you understood the SELECT, INSERT, UPDATE, and DELETE commands from earlier lessons, you already know the basics of working with MySQL.

A Brief History

MySQL was created in Sweden by a company called MySQL AB. In 2008, Sun Microsystems bought MySQL AB for about one billion dollars. Then in 2010, Oracle Corporation bought Sun Microsystems. That means Oracle now owns MySQL. This made a lot of people in the open-source community nervous. Oracle is the company behind the expensive, enterprise-focused Oracle Database, and many developers worried that Oracle might limit MySQL's open-source nature or stop investing in it.

So far, Oracle has continued to develop MySQL and keep it open source. But as insurance, the original creator of MySQL (Michael "Monty" Widenius) created a fork called MariaDB. A "fork" in software means someone took the original source code and started developing it independently in a new direction. MariaDB is designed to be a drop-in replacement for MySQL — meaning you can swap one for the other without changing your code. Many Linux distributions and organizations have switched from MySQL to MariaDB as a precaution.

What MySQL Is Great At

• Web applications — MySQL was essentially built for the web. The classic "LAMP stack" (Linux, Apache, MySQL, PHP) powered the first generation of dynamic websites, and MySQL remains the go-to database for content management systems like WordPress, Drupal, and Joomla.
• Read-heavy workloads — If your application does a lot more reading than writing (like a blog or a news site where millions of people read articles but only a few editors publish them), MySQL handles that extremely well.
• Ease of learning — MySQL has some of the best documentation and community support of any database. When you are stuck, there are thousands of tutorials, Stack Overflow answers, and forum posts to help you.
• Hosting availability — Almost every web hosting provider in the world supports MySQL. If you are deploying a small to medium-sized web application, MySQL support is practically guaranteed.

2. PostgreSQL — The Powerhouse

If MySQL is the Honda Civic, then PostgreSQL (often called "Postgres") is the Swiss Army knife. PostgreSQL is the most advanced open-source relational database available today. It can do everything MySQL can do, and then quite a bit more. It has been in continuous development since 1986 (originally as a research project at UC Berkeley), making it one of the longest-running open-source projects in history.

PostgreSQL is known for its strict standards compliance. It follows the SQL standard more closely than any other database, which means the SQL you write for PostgreSQL is more "correct" and more portable to other systems. It is also known for being incredibly extensible — you can add custom data types, write functions in multiple programming languages, and install extensions that give it entirely new capabilities.

What Makes PostgreSQL Special

PostGIS — Geographic and Location Data: One of PostgreSQL's most famous extensions is called PostGIS. It adds support for geographic data — coordinates, shapes, distances, and spatial queries. If you are building an application that needs to answer questions like "find all restaurants within 5 miles of this address" or "show me all delivery drivers currently in downtown Lansing," PostGIS makes those queries simple and fast. This is why PostgreSQL is the go-to database for mapping companies, ride-sharing apps, real estate platforms, and any application that deals with location data.

JSON Support — The Best of Both Worlds: Remember how in Lesson 20 we talked about the divide between relational databases (structured tables) and NoSQL databases (flexible documents)? PostgreSQL blurs that line. It has native support for JSON and JSONB data types, which means you can store flexible, document-style data right inside a relational table. You get the structure and reliability of SQL plus the flexibility of NoSQL, all in one database. Many teams that considered using MongoDB alongside PostgreSQL have realized they can just use PostgreSQL for everything.

Advanced Data Types: PostgreSQL supports arrays, ranges, network addresses (IP addresses), geometric types, full-text search, and more. If your data is more complex than simple text and numbers, PostgreSQL probably has a built-in type for it.

MySQL vs. PostgreSQL — How to Choose

This is one of the most common debates in the database world, and the honest answer is: both are excellent choices. Here is a simple way to think about it:

• Choose MySQL if you want the easiest setup, the widest hosting support, and you are building a straightforward web application (especially with WordPress or PHP).
• Choose PostgreSQL if you need advanced features like geographic queries, JSON storage, complex data types, or if you value strict SQL standards compliance.
• If you are starting a brand new project and both would work, either is a great choice. You cannot go wrong. Many developers have a personal preference, and that is fine.

3. MongoDB — The Flexible Document Store

MongoDB is the most popular NoSQL database in the world. Unlike MySQL and PostgreSQL, which store data in rigid tables with predefined columns, MongoDB stores data as flexible documents. These documents look a lot like JSON (the data format you learned about in earlier lessons), which makes MongoDB feel very natural if you are coming from a JavaScript or Node.js background.

Here is what a record looks like in MongoDB versus a relational database:

In MySQL (relational): You have a users table with fixed columns — id, name, email, age. Every row must have these exact columns. If you want to add a new field like phone_number, you have to change the table structure for every row.

In MongoDB (document): Each user is a document that can have whatever fields it needs. One user document might have a phone_number field while another does not. One user might have an array of hobbies while another skips it entirely. The database does not enforce a rigid structure.

// A MongoDB document (looks like JSON)
{
  "_id": "64a7f2e1b5c3d80012345678",
  "name": "Maria Garcia",
  "email": "maria@example.com",
  "skills": ["JavaScript", "React", "Node.js"],
  "education": {
    "school": "Lansing Community College",
    "degree": "Associate's in Computer Science"
  }
}

This flexibility is MongoDB's greatest strength and its greatest risk. It is great for rapid prototyping — you can start building an application without planning your exact data structure upfront. It works well for data that is naturally nested or hierarchical, like blog posts with embedded comments, or product catalogs where different products have different attributes. But the lack of structure can also lead to messy, inconsistent data if your team is not disciplined about it.

Where MongoDB Shines

• JavaScript and Node.js ecosystems — MongoDB speaks JSON natively, which makes it a natural fit for JavaScript-based applications. The "MERN stack" (MongoDB, Express, React, Node.js) and "MEAN stack" (MongoDB, Express, Angular, Node.js) are popular combinations.
• Content management — Blog posts, articles, product listings, and other content that varies in structure works well in MongoDB.
• Real-time analytics — MongoDB can ingest large volumes of data quickly, making it useful for logging, event tracking, and analytics platforms.
• Early-stage startups — When your data model is still evolving rapidly and you do not know your final table structure, MongoDB's flexibility is very attractive.

4. Redis — The Speed Demon

Redis is not quite like the other databases we have discussed. Redis is an in-memory data store, which means it keeps all of its data in your computer's RAM instead of writing it to a hard drive. Remember from Lesson 18 how we talked about RAM being incredibly fast but volatile? Redis takes advantage of that speed on purpose.

How fast is Redis? It can handle millions of operations per second. When your application needs to read or write a piece of data in under a millisecond, Redis is the tool you reach for. It is so fast that it is often used as a cache — a temporary high-speed storage layer that sits between your application and your main database.

What Redis Is Used For

• Caching — Storing frequently accessed data (like popular pages, user profiles, or product listings) for ultra-fast retrieval.
• Session storage — When you log into a website, the server creates a "session" that remembers who you are as you navigate from page to page. Redis is perfect for storing these sessions because it is fast and sessions are temporary by nature.
• Real-time features — Leaderboards in games, live vote counts, real-time notifications, and chat applications all benefit from Redis's speed.
• Rate limiting — When an API needs to limit how many requests a user can make per minute, Redis can track those counts efficiently.
• Message queues — Redis can act as a simple message broker, passing messages between different parts of your application.

Redis is rarely used as your only database. Instead, it works alongside your primary database (like MySQL or PostgreSQL) to speed things up. Think of it as the express lane at the grocery store — it handles the quick, simple transactions so the main checkout lanes can focus on the bigger jobs.

5. Other Modern Databases Worth Knowing

MySQL, PostgreSQL, MongoDB, and Redis are the "big four" that you will encounter most often. But the database world is large and growing. Here are several other important databases you should know about, even if you do not use them right away.

Elasticsearch — Full-Text Search

Have you ever used the search bar on a shopping website and noticed how it finds results even when you misspell a word, or suggests related products as you type? That is powered by Elasticsearch. It is a specialized database built for searching through large amounts of text extremely quickly. Companies like Wikipedia, GitHub, Stack Overflow, and Netflix use Elasticsearch to power their search functionality. It can search through millions of documents in milliseconds and rank the results by relevance.

Firebase / Firestore — Real-Time, Mobile-First

Firebase (and its newer version, Cloud Firestore) is a database service from Google designed for mobile and web applications. What makes it special is that it is real-time — when data changes in the database, every connected app sees the update instantly, without refreshing. It is also serverless, meaning you do not have to set up or manage a database server at all. You just write your app, and Google handles the infrastructure. Firebase is extremely popular for mobile apps, chat applications, and small to medium-sized projects where you want to get up and running fast without managing servers.

DynamoDB — AWS Cloud NoSQL

Amazon DynamoDB is a NoSQL database built by Amazon Web Services (AWS). It is designed to scale to virtually any size while maintaining consistent, fast performance. DynamoDB is "fully managed," meaning Amazon handles all the server setup, maintenance, backups, and scaling for you. If your application runs on AWS (which a huge number of companies use), DynamoDB is a common choice for workloads that need to handle massive amounts of traffic. Amazon.com itself uses DynamoDB for its shopping cart and many other features.

CockroachDB, PlanetScale, and Neon — Cloud-Native SQL

These are a newer generation of databases that combine the reliability and structure of SQL with the scalability of cloud computing. CockroachDB is a distributed SQL database that can spread your data across multiple servers (even in different countries) and survive server failures without losing data. PlanetScale is built on MySQL technology but adds features for scaling, branching (like Git branches for your database), and zero-downtime schema changes. Neon does the same for PostgreSQL. These represent the future of relational databases — all the benefits of SQL, but with built-in cloud scalability.

SQLite — The Most Deployed Database in the World

You have already met SQLite back in Lesson 14 when we used it in our Spring Boot project. Here is a surprising fact: SQLite is the single most deployed database in the world. It is not the most powerful or the most feature-rich, but it is embedded in everything. Every iPhone, every Android phone, every Mac, every Windows 10 and 11 computer, every copy of Chrome, Firefox, and Safari, every Skype installation, every copy of iTunes, every Dropbox client — all of them contain SQLite. It has been estimated that there are over one trillion active SQLite databases in the world right now.

SQLite is perfect for single-user applications and embedded systems because it stores the entire database in a single file with no server required. It is not the right choice for a web application serving thousands of users simultaneously (that is what MySQL and PostgreSQL are for), but for local storage, prototyping, testing, and embedded applications, nothing beats SQLite's simplicity.

6. Modern Database Comparison

Let us put everything we have covered into a single reference table. This is a great resource to come back to whenever you are evaluating databases for a project.

7. Choosing the Right Database — A Decision Flowchart

When you start a new project, how do you decide which database to use? Walk through this flowchart. Start at the top and follow the arrows based on your project's needs.

8. Databases in the Workplace — What You Will Actually Encounter

Understanding database technology is one thing. Understanding what you will actually encounter on the job is something else entirely. Let us walk through the major sectors of the economy and talk honestly about what databases they use and why. This is the kind of knowledge that will make you sound informed in interviews and help you set realistic expectations when you land your first role.

State and Local Government

If you get a job with the State of Michigan, a county office, or the City of Lansing, you will almost certainly encounter Oracle Database or Microsoft SQL Server. Government agencies adopted these databases decades ago and have built entire systems around them. Some older agencies still run IBM DB2 on mainframes. Newer government projects — especially those built by younger development teams or outside contractors — are increasingly using PostgreSQL because it is free, open source, and avoids expensive Oracle licensing fees. But do not expect the legacy systems to go away. Government moves slowly, and there are mainframe applications from the 1990s that are still running critical services like tax processing, driver's license systems, and welfare benefits.

Federal Government and Military

The federal government and military have the strictest security and compliance requirements of any sector. They primarily use IBM DB2, Oracle Database, and Microsoft SQL Server — all of which have special government-certified configurations. These systems handle classified information, defense logistics, intelligence data, and personnel records for millions of service members. Every database used in a federal environment must meet standards like FISMA (Federal Information Security Management Act) and FedRAMP (for cloud services). If you work in this sector, you will likely need a security clearance, and you will be working with databases that have been in place for decades.

Banks and Financial Services

Banking is one of the most database-intensive industries in the world. Every ATM withdrawal, every credit card swipe, every stock trade, every mortgage payment — all of it flows through databases. The big banks (Chase, Bank of America, Wells Fargo, Citibank) rely heavily on Oracle Database, IBM DB2, and Sybase (now SAP ASE). These are the legacy systems from Lesson 20 — expensive, battle-tested, and deeply embedded in financial infrastructure.

However, financial technology ("fintech") companies and even some departments within traditional banks are increasingly adopting PostgreSQL for new projects. PostgreSQL's reliability, strong data integrity features, and zero licensing cost make it attractive for non-legacy applications. You might also encounter Redis for caching real-time market data and MongoDB for storing less structured financial documents.

Healthcare

Healthcare databases are dominated by Microsoft SQL Server and Oracle Database. The reason is compliance: any system that stores patient health information in the United States must comply with HIPAA (Health Insurance Portability and Accountability Act). SQL Server and Oracle have robust security features, encryption, and audit logging that make HIPAA compliance more straightforward.

A unique aspect of healthcare IT is that much of the database work is vendor-specific. The two dominant electronic health record (EHR) systems — Epic and Cerner (now Oracle Health) — each come with their own database configurations. Epic primarily uses a proprietary database called Caché (now IRIS by InterSystems), while Cerner historically used Oracle. If you work in healthcare IT, you will often be working within the constraints of whatever EHR system the hospital or clinic uses, rather than choosing your own database.

Large Enterprise (Fortune 500)

If you work at a Fortune 500 company — think General Motors (right here in Michigan!), Ford, Dow Chemical, Whirlpool, or Kellogg's — expect to see Oracle Database or Microsoft SQL Server as the backbone. These companies have been using enterprise databases for decades, and their ERP systems (like SAP or Oracle E-Business Suite), HR systems, and financial systems all sit on top of these databases. Newer internal tools and customer-facing applications may use PostgreSQL or MySQL, but the core systems are almost always Oracle or SQL Server.

Mid-Size Companies

Companies with 50 to 500 employees are the sweet spot for MySQL and PostgreSQL. These companies are big enough to need real databases but not so big that they need (or can afford) Oracle's enterprise licensing. If a mid-size company in Lansing is building a web application, an internal tool, or a customer portal, odds are high they are using MySQL or PostgreSQL. You might also see SQL Server if the company is primarily a Microsoft shop (using Windows servers, .NET, and Azure).

Startups (Early Stage)

Early-stage startups — a small team of 2 to 15 people trying to build a product and find customers — almost always go with PostgreSQL or MySQL as their primary database. Both are free, well-documented, and supported by every cloud provider. Many startups also add MongoDB if their data is particularly flexible or if their team is focused on JavaScript/Node.js. Redis often shows up early too, handling sessions and simple caching.

The database stack at a typical early-stage startup might look like this: PostgreSQL for the main application data, Redis for caching and sessions, and maybe Firebase for a mobile companion app.

Startups (Growth Stage)

When a startup grows from thousands of users to hundreds of thousands or millions, the database setup gets more complex. This is when scaling issues appear. The single PostgreSQL database that worked fine for 10,000 users starts struggling under 500,000. At this point, teams start adding read replicas (copies of the database that handle read queries), Redis caching layers (to reduce the load on the primary database), and Elasticsearch (for search features that would be too slow on the main database). Some teams migrate to cloud-native solutions like PlanetScale or Amazon Aurora that handle scaling automatically.

Tech Companies (FAANG-Level)

The biggest tech companies — Meta (Facebook), Apple, Amazon, Netflix, Google, and companies of similar scale — use PostgreSQL and MySQL extensively, but they also build custom database solutions for their unique needs. Facebook created RocksDB. Google built Bigtable and Spanner. Amazon created DynamoDB and Aurora. Netflix uses Cassandra for certain workloads. At this scale, no single off-the-shelf database can handle everything, so these companies employ entire teams of database engineers who build, tune, and maintain custom systems.

But here is the thing: even at these companies, most day-to-day application development still uses PostgreSQL or MySQL. The custom databases handle specific extreme-scale challenges, while the "normal" databases handle everything else.

Agencies and Consulting Firms

If you work at a web agency, a consulting firm, or as a freelance developer, your database changes with every client. One project might be a WordPress site on MySQL. The next might be a data dashboard on PostgreSQL. The project after that might be a mobile app on Firebase. Adaptability is the skill — not deep expertise in any single database. Agencies value developers who can pick up a new database quickly, understand its core concepts, and be productive within a few days. The fundamentals you have learned in this track (SQL, relational concepts, the differences between database types) are exactly what make that adaptability possible.

The Day-to-Day Reality

Here is the career advice that will serve you well throughout your entire time as a developer: do not marry a database. Some developers become "MySQL developers" or "MongoDB developers" and tie their identity to a single technology. That is a mistake. Databases are tools, and tools change. The developer who says "I can work with whatever database the project needs" is far more valuable than the one who says "I only know PostgreSQL."

The concepts you have learned in this track — tables, rows, columns, primary keys, foreign keys, relationships, SQL queries, indexing, the difference between relational and NoSQL — those concepts apply to every database. If you understand how a relational database works, you can pick up any specific one (MySQL, PostgreSQL, SQL Server, Oracle) in a matter of days. If you understand document databases conceptually, you can learn MongoDB or DynamoDB quickly. Learn concepts, not just products.

Test Your Knowledge

Lesson Summary

This lesson gave you a bird's-eye view of the modern database landscape. Let us recap the key takeaways:

• There is no "best" database. Every database is a tool designed for specific kinds of jobs. The skill is knowing which tool to use when.
• MySQL is the most popular open-source database, ideal for web applications, and the "Honda Civic of databases." It is reliable, practical, widely supported, and what we will use for the Resumator project.
• PostgreSQL is the most advanced open-source relational database, with features like PostGIS for geographic data and native JSON support for hybrid SQL/NoSQL workloads.
• MongoDB is the leading NoSQL document database, great for flexible schemas and JavaScript ecosystems, but not always the right choice for relational data.
• Redis is an in-memory data store used for caching, sessions, and real-time features. It works alongside your primary database, not as a replacement.
• Other important databases include Elasticsearch (search), Firebase (mobile/real-time), DynamoDB (AWS scale), SQLite (embedded/mobile), and cloud-native options like CockroachDB, PlanetScale, and Neon.
• Workplace reality: Government and enterprises tend to use Oracle and SQL Server. Startups and mid-size companies lean toward PostgreSQL and MySQL. Most jobs involve two to three databases.
• Career advice: Do not marry a database. Learn the underlying concepts — they transfer across all databases. Adaptability is the most valuable skill.

In the next lesson, Lesson 22: Setting Up MySQL, you will install MySQL on your computer, create your first database, and write real SQL queries. That lesson is the bridge between understanding databases conceptually and using them hands-on. Everything you have learned across Lessons 18 through 21 has been building to this moment. Let us go make it real.