PostgreSQL vs MySQL for Multi-Tenant Healthcare: Performance Benchmarks at Scale

Every technical blog post claims to do "detailed comparisons" between databases. Most are theoretical garbage—benchmarks run on synthetic datasets with zero production context.

This post is different.

I'm going to show you real performance data from VaidyaAI's production environment—1,100+ prescriptions processed across multiple clinics, handling sensitive patient data under HIPAA-equivalent Indian compliance standards.

By the end, you'll know exactly which database to choose for multi-tenant healthcare SaaS, and more importantly, why.

The Requirements (Healthcare SaaS Is Different)

Before diving into benchmarks, let's be clear about what healthcare SaaS actually demands from a database:

1. Multi-Tenant Data Isolation (Non-Negotiable)

When Clinic A queries patient records, they should never see Clinic B's data. Not through a bug, not through a SQL injection, not through any circumstance.

This isn't just good practice—it's legal compliance. A data leak in healthcare means:

• ₹5-10 lakh penalty per record (Indian Personal Data Protection Act, 2023)
• Loss of medical license for involved practitioners
• Criminal liability for founders
• Instant business death

So our database architecture must guarantee isolation at the database level, not just application level.

2. ACID Compliance (Lives Depend On It)

In healthcare, eventual consistency is not acceptable.

Consider this scenario:

• Doctor prescribes medicine X
• Pharmacist dispenses medicine X
• Transaction fails mid-way

With eventual consistency, you might end up with:

• Prescription record: "Not dispensed"
• Inventory record: "Medicine dispensed"
• Billing record: "Payment pending"

Result: Patient doesn't get medicine, but inventory shows it was given. Or worse—double-dispensing.

We need full ACID guarantees.

3. Complex Query Performance

Healthcare queries are not simple CRUD operations. Here's a real query from VaidyaAI:

SELECT 
    p.patient_id,
    p.full_name,
    p.age,
    p.chronic_conditions,
    p.allergies,
    COUNT(DISTINCT rx.id) as total_prescriptions,
    JSON_AGG(
        JSON_BUILD_OBJECT(
            'medicine', m.name,
            'dosage', rxm.dosage,
            'frequency', rxm.frequency,
            'interaction_risk', di.severity
        )
    ) as medication_history
FROM patients p
LEFT JOIN prescriptions rx ON p.id = rx.patient_id
LEFT JOIN prescription_medicines rxm ON rx.id = rxm.prescription_id
LEFT JOIN medicines m ON rxm.medicine_id = m.id
LEFT JOIN drug_interactions di ON (
    di.drug_a = m.generic_name 
    AND di.drug_b IN (
        SELECT generic_name 
        FROM medicines 
        WHERE id IN (
            SELECT medicine_id 
            FROM prescription_medicines 
            WHERE prescription_id IN (
                SELECT id 
                FROM prescriptions 
                WHERE patient_id = p.id 
                AND status = 'active'
            )
        )
    )
)
WHERE p.clinic_id = ?
AND p.id = ?
GROUP BY p.patient_id, p.full_name, p.age, p.chronic_conditions, p.allergies;

This query involves:

• 5 table joins
• Nested subqueries
• JSON aggregation
• String matching for drug interactions

And it needs to run in under 500ms while a doctor is waiting to see the result.

4. Concurrent Write Performance

Multiple clinics are simultaneously:

• Creating prescriptions
• Updating patient records
• Recording medicine dispensing
• Processing payments

All these operations must happen concurrently without blocking each other.

Architecture Decision: Schema-Per-Tenant vs Shared Schema

Before comparing PostgreSQL vs MySQL, we need to decide on the multi-tenant architecture pattern.

Option 1: Database-Per-Tenant

clinic_1_database
clinic_2_database
clinic_3_database
...

Pros:

• Perfect data isolation (physically separate databases)
• Easy to backup individual clinics
• Can scale by moving databases to different servers

Cons:

• Expensive (separate connection pools for each tenant)
• Nightmare to maintain (schema migrations × N databases)
• Can't run cross-tenant analytics
• Connection limit issues (500 clinics = 500 databases)

Verdict: Only viable for large enterprise customers (₹50K+/month pricing).

Option 2: Schema-Per-Tenant (PostgreSQL Only)

vaidyaai_database
├── clinic_1_schema
│   ├── patients
│   ├── prescriptions
│   └── medicines
├── clinic_2_schema
│   ├── patients
│   ├── prescriptions
│   └── medicines
└── clinic_3_schema
    ├── patients
    ├── prescriptions
    └── medicines

Pros:

• Good data isolation (logical separation)
• Single database to manage
• Single connection pool
• Easier migrations (still one database)

Cons:

• PostgreSQL-only feature (MySQL doesn't have true schemas)
• Slightly more complex queries (need to set search_path)
• One backup for all tenants

Verdict: Sweet spot for most SaaS applications.

Option 3: Shared Schema with Tenant ID Column

patients
├── id
├── clinic_id    ← Tenant discriminator
├── full_name
├── age
└── ...

prescriptions
├── id
├── clinic_id    ← Tenant discriminator
├── patient_id
└── ...

Pros:

• Simplest to implement
• Works with any database
• Easy cross-tenant analytics

Cons:

• Weak data isolation (one WHERE clause bug = data leak)
• Must remember clinic_id filter in EVERY query
• Performance degrades as data grows (indexes include all tenants)

Verdict: Acceptable for low-stakes SaaS. Unacceptable for healthcare.

Performance Benchmarks: PostgreSQL vs MySQL

Before committing to PostgreSQL, I ran identical workloads on both databases to validate the decision.

Test Environment:

• Server: Hostinger VPS (4 vCPU, 8GB RAM)
• PostgreSQL 14.5
• MySQL 8.0.32
• Dataset: 500 patients, 1,100 prescriptions, 200 medicines
• Concurrent users: 10 (simulating 3 clinics)

Benchmark 1: Complex Read Query (Patient History)

Analysis: PostgreSQL's superior query planner handled the 5-way join + nested subquery much more efficiently. MySQL's optimizer struggled with the drug interaction subquery.

Benchmark 2: Concurrent Write Performance

Analysis: PostgreSQL's MVCC (Multi-Version Concurrency Control) shines here. Multiple clinics can write concurrently without blocking each other. MySQL's row-level locking caused more contention.

Benchmark 3: JSON Query Performance

We store prescription details as JSON (medicines array, dosage instructions, etc.). Both databases support JSON, but performance differs:

SELECT * FROM prescriptions 
WHERE medicines @> '[{"name": "Paracetamol"}]'::jsonb;

SELECT * FROM prescriptions 
WHERE JSON_CONTAINS(medicines, '{"name": "Paracetamol"}');

Analysis: PostgreSQL's JSONB type with GIN indexing is 4.5× faster. This matters when searching "all prescriptions containing medicine X with dosage > Y".

Benchmark 4: Full-Text Search

Doctors search patient records by name, symptoms, diagnosis. We need fast text search across multiple fields.

SELECT * FROM patients 
WHERE to_tsvector('english', full_name || ' ' || chronic_conditions) 
@@ to_tsquery('diabetes & hypertension');

Analysis: PostgreSQL wins decisively. For Indian healthcare, Hindi language support is crucial (many patient notes in Devanagari).

Real-World Production Metrics

Benchmarks are useful, but production reality is different. Here's VaidyaAI's actual performance after 3 months in production:

Pain Points We Hit (And Solved)

Problem 1: Connection Pool Exhaustion

Initial configuration: 20 max connections. Broke when 3rd clinic onboarded.

[databases]
vaidyaai = host=localhost port=5432 dbname=vaidyaai

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25
reserve_pool_size = 5
reserve_pool_timeout = 3

Result: Can now handle 1000 concurrent connections with only 25 actual database connections. Connection pooling solved it.

Problem 2: Slow Drug Interaction Queries

The nested subquery for checking drug interactions was taking 800-1200ms initially.

CREATE MATERIALIZED VIEW active_patient_medications AS
SELECT 
    patient_id,
    clinic_id,
    ARRAY_AGG(medicine_generic_name) as active_medicines
FROM prescriptions p
JOIN prescription_medicines pm ON p.id = pm.prescription_id
JOIN medicines m ON pm.medicine_id = m.id
WHERE p.status = 'active'
GROUP BY patient_id, clinic_id;

CREATE INDEX ON active_patient_medications (patient_id, clinic_id);

-- Refresh every hour
REFRESH MATERIALIZED VIEW CONCURRENTLY active_patient_medications;

Result: Query time dropped from 800ms to 42ms. 19× improvement.

Problem 3: Schema Migration Complexity

When we added a new column (allergies_verified), we had to run migration on all tenant schemas.

DO $$
DECLARE
    schema_name text;
BEGIN
    FOR schema_name IN 
        SELECT nspname FROM pg_namespace 
        WHERE nspname LIKE 'clinic_%'
    LOOP
        EXECUTE format('ALTER TABLE %I.patients ADD COLUMN allergies_verified BOOLEAN DEFAULT FALSE', schema_name);
    END LOOP;
END $$;

Result: One script migrates all tenants. Takes ~5 seconds for 10 clinics.

Why PostgreSQL Won (Beyond Performance)

The performance benchmarks clearly favor PostgreSQL, but there are other critical factors:

1. Community & Ecosystem

PostgreSQL:

• Better documentation (especially for advanced features)
• Active community (Stack Overflow, Reddit)
• Rich extension ecosystem (PostGIS for location data, pg_trgm for fuzzy search)

MySQL:

• Larger installed base (more tutorials)
• Better beginner resources
• More managed hosting options

2. License & Ownership

PostgreSQL: MIT-like license, truly open-source, community-governed

MySQL: Owned by Oracle. Open-source but with commercial implications (MariaDB fork exists for a reason)

3. Advanced Features We Actually Use

When MySQL Might Be Better

To be fair, there are scenarios where MySQL is the right choice:

1. Simple CRUD Application

If your healthcare app is just basic create-read-update-delete operations with no complex queries, MySQL's simplicity is an advantage.

2. Read-Heavy Workload with Replication

MySQL's replication is easier to set up for read replicas. If you're serving dashboards to 100+ users, MySQL's read replica setup is simpler.

3. Shared Hosting Environment

More shared hosts offer MySQL than PostgreSQL. If you're on a ₹500/month hosting plan, MySQL might be your only option.

4. Team Familiarity

If your entire team knows MySQL inside-out but has never touched PostgreSQL, the learning curve cost might outweigh technical benefits.

"The best database is the one your team can operate confidently in production. A poorly-tuned PostgreSQL setup will perform worse than a well-tuned MySQL setup."

Migration Strategy (If You're Currently on MySQL)

If you're running healthcare SaaS on MySQL and want to migrate to PostgreSQL, here's the approach we'd take:

Step 1: Schema Mapping

MySQL and PostgreSQL have subtle differences in data types:

Step 2: Data Migration

Use pgloader for automated migration:

LOAD DATABASE
    FROM mysql://user:pass@localhost/vaidyaai
    INTO postgresql://user:pass@localhost/vaidyaai
WITH include drop, create tables, create indexes, reset sequences
SET maintenance_work_mem to '512MB', work_mem to '256MB';

Step 3: Parallel Running

Run both databases in parallel for 2-4 weeks:

• All writes go to both MySQL and PostgreSQL
• Reads come from MySQL (production)
• Compare query results between both databases
• Tune PostgreSQL performance to match/exceed MySQL

Step 4: Cut Over

Switch reads to PostgreSQL, monitor for 24 hours, then deprecate MySQL.

Cost Analysis: PostgreSQL vs MySQL

Both databases are open-source, but there are hidden costs:

Hidden costs to consider:

• Developer time: PostgreSQL has steeper learning curve (20-40 hours to master)
• Hosting: Slightly more expensive for managed PostgreSQL (₹500-1000/month difference)
• Tools: MySQL has more GUI tools (phpMyAdmin, MySQL Workbench)
• Migration: If switching from MySQL, budget 40-80 hours of engineering time

Our Recommendation

For healthcare SaaS specifically, choose PostgreSQL if:

• ✅ You need multi-tenant isolation (schema-per-tenant)
• ✅ You have complex queries (joins, subqueries, JSON operations)
• ✅ You need ACID guarantees (prescriptions, billing)
• ✅ You'll use advanced features (full-text search, JSONB, arrays)
• ✅ Your team can invest 20-40 hours learning PostgreSQL

Choose MySQL if:

• ✅ Simple CRUD operations only
• ✅ Your team already knows MySQL extremely well
• ✅ You're on shared hosting with no PostgreSQL option
• ✅ You don't need advanced features

Conclusion: PostgreSQL Wins for Healthcare SaaS

After 3 months in production with 1,100+ prescriptions processed, the data is clear:

PostgreSQL outperforms MySQL on every metric that matters for healthcare SaaS:

• ✅ 1.8× faster complex queries
• ✅ 4.5× faster JSON operations
• ✅ Better multi-tenant isolation
• ✅ Stronger ACID guarantees
• ✅ Richer feature set

The learning curve is worth it. The performance gains are real. The peace of mind from proper data isolation is priceless.

If you're building healthcare SaaS in 2026, start with PostgreSQL. Your future self (and your lawyers) will thank you.