A few years ago, I was helping build a healthcare system that needed to handle everything from patient records to real-time vitals coming from wearable devices.
At first, the team had one big question: “Should we use SQL or NoSQL?”
Like many architecture debates, it started with strong opinions, whiteboard arguments, and at least one developer insisting that “MongoDB can do anything.” (We all have that person…)
But the truth revealed itself when we mapped the actual problem.
The Moment It Became Clear
We had two very different types of data flowing into the platform:
✅ 1. Highly structured clinical data
Patients, encounters, diagnoses, medications, lab results — the usual healthcare stack. This data had strict rules, relationships, and compliance requi…
A few years ago, I was helping build a healthcare system that needed to handle everything from patient records to real-time vitals coming from wearable devices.
At first, the team had one big question: “Should we use SQL or NoSQL?”
Like many architecture debates, it started with strong opinions, whiteboard arguments, and at least one developer insisting that “MongoDB can do anything.” (We all have that person…)
But the truth revealed itself when we mapped the actual problem.
The Moment It Became Clear
We had two very different types of data flowing into the platform:
✅ 1. Highly structured clinical data
Patients, encounters, diagnoses, medications, lab results — the usual healthcare stack. This data had strict rules, relationships, and compliance requirements like:
- ACID transactions
- Audit trails
- Referential integrity
- Traceability of edits and versions
- FHIR resource consistency
- HIPAA compliance
Breaking consistency in medical data isn’t just “a bug.” It can literally impact patient safety.
This pushed us firmly toward SQL — PostgreSQL, specifically — because it gives:
- clean schemas,
- rigid constraints,
- joins that actually make sense,
- and the confidence that a patient won’t “accidentally” lose a medication record during a race condition.
✅ 2. Unpredictable, high-volume data
Meanwhile, the wearable devices were sending waves of semi-structured data:
- heart rate every second
- steps
- sleep cycles
- oxygen saturation
- battery status
- alerts
- user-generated notes
The format could change tomorrow because a device manufacturer pushed an update. And the volume? Imagine thousands of patients wearing devices 24/7.
This was a perfect fit for NoSQL:
- flexible schemas (no migrations at 2 AM)
- horizontal scaling
- fast writes
- ability to store variable structures
MongoDB ended up handling these streams beautifully.
The FHIR Realization
Here’s a fun fact that many teams discover late: FHIR (Fast Healthcare Interoperability Resources) doesn’t tell you which database to use.
But FHIR does define strict shapes for core entities, such as:
- Patient
- Observation
- Encounter
- Medication
- AllergyIntolerance
- Practitioner
- Coverage
These are inherently relational. They have references, chains, and constraints that map naturally to relational databases.
FHIR servers in the real world (HAPI FHIR, Microsoft OSS, IBM) mostly use SQL internally because:
- you need version history
- you need audit trails
- you need consistency
- you need referential integrity
If a relationship between Patient → Observation breaks, a doctor sees incorrect clinical data.
That is… not ideal.
Where NoSQL Still Shines in a FHIR System
Even with a SQL backbone, NoSQL isn’t out of the picture.
We used NoSQL for:
- caching frequent FHIR bundles
- storing large telemetry from wearables
- storing semi-structured clinical notes
- fast document retrieval
- chat messages in telemedicine
- queuing and event streaming
It became clear quickly:
👉 SQL protects your source of truth. 👉 NoSQL helps your system breathe under pressure.
The Architecture That Finally Worked
At the end of our experiments, we landed on a hybrid structure:
🔥 SQL (PostgreSQL) for:
- patient master data
- encounters & admissions
- lab results
- insurance & claims
- FHIR resource storage
- audit logs
- system-of-record data
🔥 NoSQL (MongoDB + Redis) for:
- real-time device data
- logs & event streams
- semi-structured notes
- caching layers
- large payloads that don’t belong in relational tables
Over time, the system grew comfortably around this combination. SQL gave reliability. NoSQL gave speed and flexibility.
So When Should You Use Each?
✅ Use SQL when your data:
- is structured
- is relational
- must remain consistent
- requires transactions
- needs auditing
- maps to FHIR resources
- plays a role in compliance
✅ Use NoSQL when your data:
- changes shape frequently
- comes in high volume
- needs fast writes
- is semi-structured or unstructured
- doesn’t require strict relational constraints
Final Thought
Choosing between SQL and NoSQL isn’t a battle. It’s a balancing act.
If you’re building healthcare software — especially anything involving FHIR — you’ll almost always end up using both, each playing to its strengths.
And trust me… Your future self (and your future on-call phone) will be grateful you didn’t try to force all data into one box.