HARD TRUTHS

❓ THE QUESTION

Does COBOL even need to die?

After working through side-by-side comparisons, you might be surprised at the answer.

🦕 COBOL: THE HONEST DINOSAUR

What We Usually Hear

• "COBOL is dead"
• "Legacy technology"
• "Nobody uses it anymore"
• "Time to rewrite everything in [insert trendy tech]"

The Uncomfortable Truth

COBOL is still running critical infrastructure, and in some ways, it's more honest than modern alternatives.

1. Explicit Control

       OPEN INPUT EMPLOYEE-FILE.
       READ EMPLOYEE-FILE KEY IS EMP-ID.
       IF WS-SUCCESS
           DISPLAY EMP-FIRST-NAME
       ELSE
           DISPLAY "Not found"
       END-IF.
       CLOSE EMPLOYEE-FILE.

Every single operation is explicit: You open files. You read them. You check status codes. You close them.

No magic. No surprises. No "framework updated, your app broke."

2. Fixed-Point Arithmetic

       05 EMP-SALARY    PIC 9(7)V99.

This is a DECIMAL number with EXACTLY 2 decimal places. No floating-point rounding errors. No surprise pennies disappearing. When you're calculating payroll for millions of employees, this matters.

3. Compile-Time Guarantees

       01  EMPLOYEE-RECORD.
           05 EMP-ID               PIC X(4).
           05 EMP-FIRST-NAME       PIC X(20).

Every record is EXACTLY 78 bytes. Always. Forever.

No runtime "undefined is not a function." No "cannot read property of null." Your program either compiles or it doesn't.

4. Batch Processing Excellence

COBOL was designed for one thing: process millions of records efficiently in batch jobs.

And it STILL does this better than most modern alternatives:

• Low memory footprint
• Predictable performance
• Sequential I/O optimized for tape/disk
• No garbage collection pauses

Modern "streaming" frameworks are often just reinventing COBOL's batch processing with more RAM.

⚡ SQL: THE DECLARATIVE POWERHOUSE

What We Usually Hear

• "NoSQL is the future"
• "SQL doesn't scale"
• "Too rigid for modern apps"
• "Who needs ACID anyway?"

The Uncomfortable Truth

SQL is declarative genius, and most NoSQL "solutions" end up rebuilding worse versions of it.

1. You Say WHAT, Not HOW

SELECT first_name, salary
FROM employees
WHERE department = 'Engineering'
  AND salary > 80000
ORDER BY salary DESC;

The database figures out the optimal execution plan.

You don't manually loop. You don't manually index scan. You describe your intent, and a query optimizer with decades of research behind it does the work.

2. ACID Transactions

BEGIN TRANSACTION;
  UPDATE accounts SET balance = balance - 100 WHERE id = 'A';
  UPDATE accounts SET balance = balance + 100 WHERE id = 'B';
COMMIT;

Either both updates happen, or neither does. No partial state. No corruption.

This is not "legacy thinking" – this is fundamental correctness for financial systems, e-commerce, inventory management, and countless other domains.

3. Relational Integrity

FOREIGN KEY (user_id) REFERENCES users(id)

The database ENFORCES that relationships make sense.

You can't have orphaned records. You can't delete a user who still has orders. The database is your safety net.

Modern NoSQL approach: "Just be careful in application code" (pushing database-level guarantees into application logic, where they're easier to get wrong)

4. Decades of Optimization

SQL databases have:

• Cost-based query optimizers
• Covering indexes
• Partial indexes
• Statistics and histograms
• Decades of research on efficient join algorithms, concurrency control, and recovery mechanisms

When you choose a NoSQL database, you're often giving up this entire optimization ecosystem.

🚀 MONGODB: THE FLEXIBLE REBEL

What We Usually Hear

• "Just use PostgreSQL JSONB"
• "MongoDB is web scale" (meme)
• "Schemaless chaos"
• "Can't do joins, useless"

The Uncomfortable Truth

MongoDB is genuinely useful when used for its intended purpose, and some problems truly benefit from document-orientation.

1. Schema Flexibility

// v1 of your product catalog
{
  _id: "product1",
  name: "Widget",
  price: 29.99
}

// v2 - just add new fields, no migration
{
  _id: "product2",
  name: "Gadget",
  price: 49.99,
  variants: [
    { size: "small", sku: "GAD-S" },
    { size: "large", sku: "GAD-L" }
  ],
  reviews: [
    { user: "john", rating: 5, text: "Great!" }
  ]
}

No ALTER TABLE. No downtime. No migration scripts.

2. Embedding Related Data

// Blog post with embedded comments - ONE query
{
  _id: "post123",
  title: "My Blog Post",
  content: "...",
  comments: [
    { user: "alice", text: "Great post!", date: "2024-01-15" },
    { user: "bob", text: "Interesting", date: "2024-01-16" }
  ]
}

For data that's genuinely hierarchical and accessed together, embedding is efficient.

No joins needed. No N+1 queries. Fetch the document, get everything you need.

3. Developer Ergonomics

// JSON-native API
db.products.find({ category: "electronics", price: { $lt: 100 } })

// vs SQL string building (before ORMs)
"SELECT * FROM products WHERE category = 'electronics' AND price < 100"

Working with JSON data in a JSON database with a JSON API feels natural for web developers.

4. Horizontal Scalability (When You Actually Need It)

MongoDB's sharding is built-in and (relatively) easy to set up.

🎯 THE REAL LESSON

Match the Tool to the Problem

⚠️ THE UNCOMFORTABLE TRUTH ABOUT "MODERN"

"Modern" doesn't mean "better" – it means "recent."

❌ Resume-Driven Development

Choosing MongoDB because:

• "It's what the cool companies use"
• "It's on my resume"
• "SQL is old"
• "We might need to scale someday"

This is how you end up with COBOL-style sequential scanning in Node.js.

✓ Engineering-Driven Development

Choosing a database because:

• You understand your access patterns
• You know the trade-offs
• You've measured (or can estimate) your scale
• The technology fits the problem

This is how you build systems that last.

💎 THE HARD TRUTH

💭 FINAL THOUGHT

Every technology in this comparison is still in active use in 2024.

They all survived because they're good at something.

The question isn't "which is best?" – it's "which is best for THIS problem?"

📚 EXPLORE MORE