Results at a glance

What Magicare does and why our database matters

Magicare is building the agentic operating system for post-acute care (PAC). At its core, Oracle - our clinical inference engine, reads hundreds of pages of clinical documentation per patient and can truthfully answer any question about that patient. Oracle doesn't just retrieve; it predicts, mapping future care pathways so PAC providers (skilled nursing facilities, home health, rehab, and hospice) can route each patient to the optimal journey and maximize quality of care.

Around Oracle, our platform handles admissions, prior authorizations, revenue cycle management (claims), and compliance: the operational stack PAC providers depend on every day.

Every day, our system:

• Processes thousands of new patient referrals

• Reads tens of thousands of pages of PDF clinical documentation

• Generates more than 5 billion LLM tokens

• Runs thousands of headless browser bots 24/7 (shoutout to @Browserbase!) that log in to payer and EHR portals, capture state, and write data back

Our users expect insights with custom rules for their organization, all in real-time. That puts a lot of weight on the database underneath everything we ship.

The problem: self-hosted Postgres on Hetzner hit a wall, and the wall was the disk

We wanted the best bang for our buck, so we ran a self-hosted Postgres on Hetzner: a 48 vCPU / 192 GB RAM dedicated server for about $800/month, including extra network-attached volumes. On paper, that's a powerful database.

In practice, we hit three problems.

1. Disk speed was the bottleneck, not CPU or Ram

We thought we'd run out of compute; we didn't. Hetzner's read/write speeds are "secretly" low: the main disk does roughly 300 MB/s, and the network-attached volumes you have to scale onto are even slower, around 50 MB/s. Once disk is your bottleneck, throwing more vCPUs at the problem doesn't help. One of our (core) materialized views took 13+ minutes to refresh.

2. A single database doing every read and every write

Provisioning and maintaining Postgres replicas by yourself is non-trivial work, and we kept punting on it. That meant a single point of failure was constantly front and center. There was no graceful failover. If that one box went down, the product went down.

3. Hardware that goes bad on you

Maintaining your own infrastructure is hard enough; when something goes wrong, either you have the right scripts in place to auto-detect and fix it, or you are personally on the line. Cheap hardware fails. We even ran into damaged on-disk tuples. Not a fun day.

Performance, reliability, and scaling all bottlenecked on the same root cause: we were running a fast inference engine on a slow disk.

Why we chose PlanetScale

If you've ever run a high-throughput Postgres workload at scale, you already know PlanetScale is the answer. The reputation, the customer roster, and the support team are all best-in-class. “Unlimited IOPS” is the kind of headline you can only put on a marketing page if you've actually built the thing.

The only reason we hadn't moved sooner was overconfidence: we thought we could run a high-load Postgres ourselves — until this simply didn’t work at scale.

Migration & onboarding: first conversation to live writes — four days

This was honestly my favorite part of the whole project. Here's how it actually went.

Day 1 : The database review

PlanetScale gave us a script to run against our Postgres. It outputs a JSON file that their team feeds into an internal tool that surfaces real metrics about your workload: query mix, hot tables, index usage, bad patterns. From outreach to a live, the data-driven review of our database was about 24 hours and they came back with a specific, opinionated recommendation about the instance size and topology that would actually fit the shape of our load. They flagged things we would have missed on our own.

Open-source request to the PlanetScale team: please ship that internal tool publicly! It would be a gift to the entire Postgres community.

Days 2–4: The setup

A shared Slack channel was up immediately. Read replicas and automatic failover were stood up by default: no failover scripts, no pager-fueled chmod 700 side quest. PgBouncer was trivial to configure: one pool for the writer, one for the read replicas, all through a UI that’s hard to mess up but still exposes the advanced options underneath.Day 4: Going Live

We were on PlanetScale, in production, in about a day of actual switchover work. Start to finish, from first conversation to live writes, was about four days.

The Results

Numbers tell the story:

• 85%+ reduction in query latency.

• 17× faster materialized view refreshes: 13+ minutes → ~45 seconds.

• 6× smaller database footprint per instance: 48 vCPU / 192 GB RAM (Hetzner) → 8 vCPU / 64 GB RAM (PlanetScale) — the new setup is meaningfully faster.

• Automatic read/write replicas and failover — no more single point of failure.

• Disk is no longer the bottleneck. PlanetScale Metal's drive speed is what makes Oracle feel real-time.

Magicare is noticeably faster end-to-end, not only benchmark-faster, but even users can feel that it's faster. It costs more than the Hetzner box, but not by much, and it has been worth every dollar.

Favorite PlanetScale features

• Worry-free read replicas, set up by default. We stopped writing failover scripts.

• PgBouncer configuration that's a one-click affair. One in front of the writer, one in front of the replicas, with the UI making it obvious where to point what.

• PlanetScale Insights surfaces unused indexes, wasted indexes, and the specific queries dragging the database down. It paid for itself in week one.

• Power buried under a simple UI: every advanced configuration is one click away, but you never get punished for not touching it.

Support experience

Direct, fast, and zero time wasted. The team guided us through the entire migration with specific options and recommendations rather than generic links to docs. The actual cutover took under a day on our end.

What's next

1. Magicare is staying on PlanetScale indefinitely.

2. We're moving our vector database over to PlanetScale next (it's also on Hetzner today).

3. For every new project going forward, PlanetScale is our default Postgres. It replaces every previous “let's self-host” or “let's start on Supabase” reflex.

About Magicare

Magicare is the agentic operating system for post-acute care. Oracle, Magicare.AI's clinical inference engine, powers admissions, prior authorizations, revenue cycle, and compliance for nearly post-acute care facilities, improving care for tens of thousands of patients. Learn more at Magicare.ai.

Want to work with us? Reach out at magicare.ai/contact-us.