DEV Community: Ashish Singh

Choosing MongoDB Was The Biggest Mistake Of My College Life😥

Ashish Singh — Fri, 20 Mar 2026 12:49:57 +0000

It was the final year of my college, and I was left with 6 months to build my major project, which was a healthcare app

{(Patients), (doctors), (appointments), (prescriptions)} All data were connected to each other in a hierarchical relation.

I picked MongoDB because people around me were using it. Spent two months building on it, hit three problems I could not cleanly solve, and migrated to PostgreSQL before submission.

Why MongoDB made sense at the start

When requirements are changing every week, the last thing you want is to deal with database migrations. MongoDB lets you skip that. No schema upfront, just start inserting data and add fields as you go.

// Week 1
{ name: "Rahul", age: 24, phone: "9876543210" }

// Week 3, requirements changed
{ name: "Rahul", age: 24, phone: "9876543210", bloodGroup: "O+", doctorId: "abc123" }

That doctorId is a plain string pointing to a doctor document. No foreign key. No constraint. If that doctor gets deleted, this field sits there pointing at nothing, and MongoDB does not throw a single error.

That part I figured out much later.

Problem 1: Without a schema, your data becomes inconsistent without you noticing

A blood group is one of eight values. An age is a positive number. These are fixed, they do not change shape from patient to patient.

By week four I had three versions of the same field across my patient documents.

{ name: "Patient A", bloodGroup: "O+" }
{ name: "Patient B", blood_group: "B-" }   // different key name
{ name: "Patient C" }                       // field just missing

All three valid. Zero errors. When I queried patients for blood group, I got back maybe 60% of the actual results because the rest were stored under a different key name.

I ended up writing code to normalize all three formats before querying. That is time spent fixing a problem that the database should have prevented in the first place.

Problem 2: No joins means you manually assemble related data in code

Every feature in a healthcare app touches multiple entities. Patient has appointments. An appointment belongs to a doctor. Prescription ties all three together.

MongoDB has no joins, so every time I needed data from two collections, I fired multiple queries and pieced the result together myself.

const appointments = await Appointment.find({ patientId: id });

const result = await Promise.all(
  appointments.map(async (appt) => {
    const doctor = await Doctor.findById(appt.doctorId);
    return { ...appt._doc, doctor };
  })
);

One query per appointment just to get the doctor's name. A patient with 10 appointments means 11 database round trips. I was doing this across every endpoint in the app.

The same thing in PostgreSQL:

SELECT a.appointment_date, a.status, d.name, d.specialization
FROM appointments a
JOIN doctors d ON a.doctor_id = d.id
WHERE a.patient_id = $1;

One query. When I got this working for the first time, I sat staring at it for a minute because of how much code it replaced.

Problem 3: Two operations with no transaction means broken data is a real possibility

Booking an appointment needs two things to happen together.

Create the appointment record
Mark that doctor's slot as unavailable

If the first succeeds and the second fails, the slot still shows as open. Another patient books the same slot. Same doctor, same time, two confirmed appointments.

My workaround was manual rollback logic in application code.

try {
  const appointment = await Appointment.create(data);
  try {
    await Doctor.updateOne(
      { _id: doctorId },
      { $pull: { availableSlots: slot } }
    );
  } catch (err) {
    await Appointment.deleteOne({ _id: appointment._id });
    throw err;
  }
} catch (err) {
  res.status(500).json({ error: "Booking failed" });
}

The cleanup itself can fail. You end up with partial state and no reliable way to detect it.

PostgreSQL handles this with a transaction.

BEGIN;
  INSERT INTO appointments (patient_id, doctor_id, slot, status)
  VALUES ($1, $2, $3, 'confirmed');

  UPDATE doctor_slots
  SET is_available = false
  WHERE doctor_id = $2 AND slot = $3;
COMMIT;

If anything fails, the whole thing rolls back. No cleanup code needed. No partial state to debug at 2 AM.

What the PostgreSQL schema looked like

Writing the schema upfront felt slow. It also caught three design mistakes I would have discovered much later in application code.

CREATE TABLE patients (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  age INTEGER CHECK (age > 0 AND age < 150),
  blood_group VARCHAR(3) CHECK (
    blood_group IN ('A+','A-','B+','B-','AB+','AB-','O+','O-')
  ),
  phone VARCHAR(15) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE appointments (
  id SERIAL PRIMARY KEY,
  patient_id INTEGER REFERENCES patients(id) ON DELETE CASCADE,
  doctor_id INTEGER REFERENCES doctors(id),
  slot TIMESTAMP NOT NULL,
  status VARCHAR(20) DEFAULT 'pending',
  UNIQUE(doctor_id, slot)
);

The CHECK on blood_group means the database rejects anything outside those eight values. The three-versions-of-the-same-field problem from MongoDB cannot happen here.

The UNIQUE(doctor_id, slot) makes double booking impossible at the database level. Not something I validate in code. Not something I have to remember to check. The second insert just fails.

Where MongoDB actually fits in healthcare

Not saying avoid it entirely. There are cases where it makes sense.

Unstructured clinical notes where fields genuinely differ per patient. IoT device readings with unpredictable schemas. Medical imaging metadata. These are cases where the data does not have a fixed shape and MongoDB's flexibility is actually useful.

But patient records, appointments, prescriptions, doctor schedules? That data is relational and always has been. Putting it in MongoDB means you end up writing the referential integrity, the transaction logic, and the constraint validation yourself in application code. You are just reinventing the things PostgreSQL gives you by default.

What I would do differently

I wasted two months because I picked a database based on what friends were using instead of looking at the actual shape of my data.

If data has a fixed structure and clear relationships between entities, PostgreSQL is the right call. Schema up front, foreign keys, transactions, joins. None of that has to live in your application code.

The two hours you spend defining the schema will save you from the kind of bugs that only show up when two requests hit the database at the same time, or when one operation out of three fails halfway through.

I Replaced Cron Jobs with Node Cron in My SaaS. Here's What Broke.

Ashish Singh — Wed, 18 Mar 2026 09:56:51 +0000

node-cron seems like the obvious choice when you're building a Node.js SaaS and need scheduled tasks. It integrates into your codebase, uses familiar cron syntax, and takes about five minutes to set up.

The problem is that it also fails in ways that are hard to notice until they hit production.

I used node-cron for scheduling digest emails, session cleanup, and third-party data syncs. Here's every problem I encountered, why it happened, and what I replaced it with.

What node-cron actually does

It runs cron jobs inside your Node process. That's the entire value proposition.

npm install node-cron

import cron from 'node-cron';

cron.schedule('0 8 * * *', () => {
  sendDailyDigestEmails();
});

No external scheduler. No separate process. The job lives and dies with your Node app.

That convenience also causes all the issues listed below.

Problem 1: Multiple instances run the same job

We were running two app instances for redundancy. Both had the same codebase. At 8 AM, both instances executed sendDailyDigestEmails() at the same time.

Users received two emails. Some received three during a period when we had three instances running. Support tickets came in immediately.

node-cron has no awareness of other instances. It does not coordinate. It does not lock. Every process with the same code runs the same job.

Fix: Distributed lock with Redis

Before executing any job, the instance attempts to acquire a lock. If it fails, another instance is already handling it.

import { createClient } from 'redis';
import cron from 'node-cron';

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

async function acquireLock(key, ttlSeconds) {
  const result = await redis.set(key, '1', {
    NX: true,       // Set only if key does not exist
    EX: ttlSeconds  // Auto-expire after TTL
  });
  return result === 'OK';
}

cron.schedule('0 8 * * *', async () => {
  const acquired = await acquireLock('lock:daily-digest', 300); // 5 min TTL

  if (!acquired) {
    console.log('Job already running on another instance. Skipping.');
    return;
  }

  await sendDailyDigestEmails();
});

The TTL is important. If the instance acquires the lock and crashes mid-execution, the lock does not stay permanently and block all future runs.

Problem 2: Jobs disappear on restart

We deploy multiple times a day. Every deployment restarts the Node process.

If a job was scheduled for 3 AM and a deployment happened at 2:58 AM, the job simply did not run. node-cron has no persistence. When the process restarts, the scheduler starts fresh from that moment.

For email digests, a missed run is an inconvenience. For billing jobs or third-party syncs, a missed run can cause real data inconsistencies.

Fix: BullMQ for critical jobs

BullMQ stores repeatable jobs in Redis. The schedule survives process restarts because it lives in Redis, not in memory.

import { Queue, Worker } from 'bullmq';

const emailQueue = new Queue('email-tasks', {
  connection: { url: process.env.REDIS_URL }
});

// Run once on startup. BullMQ deduplicates via jobId.
await emailQueue.add(
  'daily-digest',
  {},
  {
    repeat: { cron: '0 8 * * *' },
    jobId: 'daily-digest'
  }
);

const worker = new Worker('email-tasks', async (job) => {
  if (job.name === 'daily-digest') {
    await sendDailyDigestEmails();
  }
}, { connection: { url: process.env.REDIS_URL } });

Even if the app restarts 10 times before the scheduled time, the job still fires when it's supposed to.

After this change, I kept node-cron only for non-critical tasks where missing a run has no real impact, like clearing an in-memory cache.

Problem 3: Failed jobs produce no output

This is the one that cost us the most time.

cron.schedule('0 8 * * *', () => {
  sendDailyDigestEmails(); // Not awaited. No catch.
});

If this function throws, nothing happens. node-cron does not catch rejected promises. No error log. No alert. No retry. The next scheduled run attempts again, fails again, and you still have no idea.

We had a job silently failing for 11 days because a function was renamed during a refactor. The job ran on schedule, called undefined, threw an error, and the error was swallowed completely.

Fix: Wrap every callback in a guard function

async function runWithGuard(jobName, fn) {
  try {
    console.log(`[cron] Starting: ${jobName}`);
    const start = Date.now();
    await fn();
    console.log(`[cron] Completed: ${jobName} in ${Date.now() - start}ms`);
  } catch (err) {
    console.error(`[cron] Failed: ${jobName}`, err);
    await notifySlack(`Cron job failed: ${jobName}\n${err.message}`);
  }
}

cron.schedule('0 8 * * *', () => {
  runWithGuard('daily-digest', sendDailyDigestEmails);
});

Every job now produces a start log, a completion log with duration, or a failure log with a Slack notification. This one change alone caught five incidents that would have gone unnoticed.

Problem 4: Timezone mismatches

Our server runs on UTC. Most users are in IST (UTC+5:30) or US Eastern (UTC-5). We scheduled a morning email for 8 AM.

Indian users received it at 1:30 PM.

node-cron defaults to the server process's timezone. 0 8 * * * on a UTC server fires at 8 AM UTC, which is 1:30 PM IST. This is documented behavior, but it is easy to miss.

Fix: Set timezone explicitly per job

node-cron accepts a timezone option. Use it.

cron.schedule('0 8 * * *', () => {
  runWithGuard('morning-email-india', () => sendMorningEmail('IN'));
}, {
  timezone: 'Asia/Kolkata'
});

cron.schedule('0 8 * * *', () => {
  runWithGuard('morning-email-us', () => sendMorningEmail('US'));
}, {
  timezone: 'America/New_York'
});

If you need per-user timezone scheduling where each user gets an email at 8 AM their local time, cron is not the right tool. You need a job queue where each job carries timezone metadata, and you compute the UTC fire time per user. For region-level grouping, the timezone option works fine.

Problem 5: No visibility into what is scheduled

With a standard crontab, you can run crontab -l and see every registered job. With node-cron, there is nothing built-in. No dashboard. No last-run timestamp. No next-run time.

The 11-day silent failure mentioned above was only discovered because a user complained that data was not updating. It could have continued for weeks.

Fix: A job registry with a health endpoint

const jobRegistry = new Map();

function registerJob(name, schedule, fn, options = {}) {
  const task = cron.schedule(schedule, async () => {
    const meta = jobRegistry.get(name);
    meta.lastRunAt = new Date();
    meta.status = 'running';

    await runWithGuard(name, fn);

    meta.status = 'idle';
    meta.lastSuccessAt = new Date();
  }, options);

  jobRegistry.set(name, {
    schedule,
    status: 'idle',
    lastRunAt: null,
    lastSuccessAt: null,
    task
  });
}

registerJob('daily-digest', '0 8 * * *', sendDailyDigestEmails, {
  timezone: 'Asia/Kolkata'
});

app.get('/healthz/crons', (req, res) => {
  const jobs = Object.fromEntries(
    [...jobRegistry.entries()].map(([name, meta]) => [name, {
      schedule: meta.schedule,
      status: meta.status,
      lastRunAt: meta.lastRunAt,
      lastSuccessAt: meta.lastSuccessAt
    }])
  );
  res.json(jobs);
});

An uptime monitor hits /healthz/crons every five minutes. If any job's lastSuccessAt is older than its expected interval, something is broken. The setup takes 20 minutes. The value is immediate.

When node-cron is actually the right choice

node-cron is not a bad library. It has a clear use case.

It works well when:

You are running a single instance
Missing an occasional run has no real consequence
The task is lightweight and non-critical
You do not want to introduce Redis just for one job

It becomes a problem when:

You are running multiple instances
You deploy frequently
You need retry logic on failure
You need any observability without building it yourself

What I would set up from day one

BullMQ with repeatable jobs for anything business-critical: billing, emails, external API syncs
node-cron only for throwaway housekeeping that is safe to miss
Redis distributed lock on every node-cron job as a safety net
Job registry with health endpoint before anything reaches production
Every cron callback is async/await with try/catch, no exceptions

Setting up BullMQ with a repeatable job takes about 20 minutes. Debugging the double-email incident and writing apology emails to users took most of a workday. The tradeoff is obvious in hindsight.

If you are currently using node-cron in a multi-instance environment without locks or observability, that is worth fixing before the next incident surfaces it for you.

Curious if anyone has moved to Temporal or Inngest for scheduled jobs in Node. Drop it in the comments.