DEV Community: Martin Janse van Rensburg

HIPAA compliant databases will bankrupt you as fast as US healthcare

Martin Janse van Rensburg — Fri, 30 Oct 2026 22:22:14 +0000

A question keeps coming up in dev forums: "We're a three-person health startup. Do we really need an enterprise contract to get a HIPAA compliant database?" The honest answer in 2026 is no. But the pricing pages don't make that easy to see. Between "contact sales" buttons, add-ons that aren't priced in public, and surcharges that only show up in the docs, figuring out what fully managed HIPAA compliant database hosting really costs takes an afternoon of digging. I did the digging for managed databases, the kind where someone else runs the servers, backups and patching for you. Here are the numbers.

Disclosure: I work at Prisma, which is one of the providers below. I've kept this to public prices and linked every number to the provider's own page so you can check my math.

The contrarian take: HIPAA isn't an enterprise feature

HIPAA doesn't certify databases. There's no "HIPAA edition" that magically makes data safe. What HIPAA needs from a database vendor is mostly paperwork plus solid basics: a signed Business Associate Agreement (BAA) and real safeguards around the data.

So why do so many vendors put it behind a sales call? Some genuinely run a separate, locked-down environment for regulated customers. Others just use HIPAA as a reason to start an enterprise deal. Either way, the result for a small team is the same: you can't get a price without a meeting.

I think that's the wrong default. A startup should be able to read a pricing page, pick a plan and know what HIPAA will cost per year.

What a fully managed HIPAA compliant cloud database costs per year in 2026

Two rules for this list: the database is fully managed, and the BAA comes with the plan. Providers that review each BAA request and approve it case by case are left out, because you can't budget for something you might not get. Sorted cheapest first. Annual cost is monthly times 12. "Estimate" means the bill depends on usage, and I priced the smallest always-on setup.

Provider	Cheapest HIPAA option	Per month	Per year	What's included	The fine print
Neon	Scale plan	~$44	~$528	About 0.25 CU (1 CU is about 4 GB RAM) billed hourly, 10 GB at $0.35/GB, instant restore up to 30 days (billed), HA not stated, SOC 2 report and ISO 27001	Estimate. HIPAA docs say a 15% surcharge is coming
MongoDB Atlas	M10 cluster	~$58	~$701	2 shared vCPUs, 2 GB RAM, 10 GB storage, replica set, backups billed separately, SOC 2 and ISO not stated on pricing page	MongoDB suggests M30 (~$394/mo) for sensitive data
Prisma Postgres	Business plan	$129	$1,548	50M operations, 100 GB storage, daily backups kept 30 days, Premium support, SOC 2 Type II, ISO 27001, BAA included	Flat price with usage included. No HIPAA fee. HIPAA isn't on lower plans
Heroku Postgres	Shield-0	$350+	$4,200+	4 GB RAM, 68 GB storage, rollback up to 7 days, high availability (Premium tier feature), dedicated environment, HIPAA and PCI	Also needs a Shield Private Space through Heroku Enterprise, price not listed
Render	Scale workspace + smallest Postgres	~$506	~$6,074	0.1 CPU, 256 MB RAM, 1 GB SSD ($0.30/GB more), logical backups and 7 day PITR, HA not in this estimate, workspace audit logs, SOC 2 and ISO not stated on pricing page	$499/mo workspace, plus 20% on compute for HIPAA
CockroachDB	Mission Critical	~$710	~$8,515	3 dedicated nodes x 2 vCPU, storage billed extra, hourly backups kept 30 days (billed), multi node by design, SOC 2 and ISO not stated on pricing page	Estimate for 3 nodes x 2 vCPU, before storage
Supabase	Team + HIPAA add-on	~$1,054	~$12,648	Small shared compute with 2 GB RAM, 8 GB disk, daily backups kept 14 days plus 7 day PITR, HA not stated, SOC 2 and ISO 27001	$599 Team plan, plus a HIPAA add-on that isn't priced publicly (reported at ~$350/mo), plus $100/mo backups that HIPAA projects need

No public HIPAA price at all: Crunchy Bridge (you contact them for a BAA), Railway (Enterprise only), Aiven (a separate compliance environment with a commitment deal), Tiger Data (Enterprise only) and Xata (bring your own cloud, with a yearly minimum).

No BAA for managed databases: DigitalOcean will sign a BAA, but Managed Databases aren't on its covered list.

Reading the fine print

Hidden add-ons. Supabase's headline is $599 a month, but HIPAA sits in an add-on with no public price, and the backups it needs cost extra. That's how a $7k plan turns into roughly $12.6k. Render's $499 workspace also adds 20% to compute once HIPAA is switched on. Heroku lists the Shield database price but not the private space it needs.

Why there's no AWS, Google Cloud or Azure. All three sign a BAA at no extra cost, but on their own they're building blocks you configure and run yourself: networking, IAM, logging, backup policies and sizing are your job. This post compares fully managed databases, so I left them out.

Announced price changes. Neon includes HIPAA on its Scale plan today, but its docs say a 15% surcharge will be added, with notice. Budget for it.

None of this makes those providers bad choices. It just means the cheapest number in a table and your real annual bill aren't the same thing.

Which one fits

There's no single winner. It depends on how you want to pay and what you already run.

You want the lowest bill at a tiny size: Neon or MongoDB Atlas, as long as you budget for Neon's coming surcharge and MongoDB's advice to size up for sensitive data.
You want a flat yearly number with usage included: Prisma Postgres. Details are on its HIPAA compliant database page.
You're already on Heroku or Render: staying put saves a migration, but HIPAA there means moving up to their higher tiers.
You need Postgres features Supabase adds on top (auth, storage, realtime): Supabase, at the highest price on this list.

What HIPAA actually needs from your database

Whichever managed provider you pick, check for these five things:

A signed BAA before any patient data touches the database. No BAA, no PHI. Simple as that.
Encryption at rest and in transit. Check that TLS is enforced for connections, not just offered.
Access controls. Limit who can see the workspace, the database and the connection strings. Rotate credentials when people leave.
Audit trails. You need to be able to show who did what. Some of this comes from your provider, and some from your own app logs (keep PHI out of those logs).
Backups you've tested. Know how long backups are kept and do a practice restore before you need one.

Remember that HIPAA is shared responsibility. The provider secures the platform. You secure your app, your team's access and your own policies.

Getting a BAA signed

The steps are similar everywhere:

Pick a plan where HIPAA is included, and check what the BAA covers. Some only cover the database, not other products from the same vendor.
Read the provider's standard BAA and share it with whoever handles legal on your team.
Request the BAA (usually a form or an email to a compliance address) and sign it.
Only then put patient data in the database.

How I calculated this

Fully managed databases only. Raw cloud services you run yourself are left out.
BAA included with the plan. Providers that review and approve BAA requests case by case are left out.
Prices were taken from each provider's public pricing and HIPAA pages in October 2026, US regions, list prices, before tax.
Annual = monthly x 12. No discounts, reserved instances or committed-use deals.
For usage-billed services I priced the smallest always-on setup that can be covered by a BAA, with minimal storage. Your bill will depend on traffic and data size.
The Supabase HIPAA add-on price isn't published. The ~$350/mo figure is a reported quote, not an official price.
Prices change. If you spot something out of date, tell me in the comments and I'll update the table.

HIPAA shouldn't be a reason to sign an enterprise contract before you've found product-market fit. Read the fine print, budget for the real setup, and pick the managed provider whose price you can actually see.

Great article by Shubra. I hope everyone gives the new Prisma a try. It's not an ORM anymore.

Martin Janse van Rensburg — Thu, 29 Oct 2026 10:28:20 +0000

AI-generated code uncovers a nasty connection bug

Shubhra Pokhariya

Oct 29

Hono on Prisma Postgres and Compute, What Worked and What Broke

#prisma #postgres #typescript #backend

11 min read

Zero-downtime Postgres migration with logical replication: the checklist we actually used

Martin Janse van Rensburg — Mon, 26 Oct 2026 23:14:05 +0000

Most advice about moving a production database boils down to "schedule a maintenance window and run pg_dump". That works until customers use your product around the clock and six services write to the same database.

That was our situation. The database behind our own Console (every workspace, project and API key) lived on Amazon RDS, and we wanted it on Prisma Postgres, the managed Postgres we run for our users. We moved 83 tables and 74 GB without pausing writes, and we could have switched back to RDS for a full week afterwards without losing a row.

This is the checklist we'd hand a friend about to do the same thing, plus the SQL that mattered and the one thing that bit us.

Why logical replication and not dump/restore

A dump and restore is a snapshot. Anything written after the snapshot is lost unless you stop writes until the restore finishes. On 74 GB that's not a short pause.

Logical replication is built into Postgres and works differently. The old database publishes row changes, the new one subscribes. The subscriber copies each table once, then keeps applying inserts, updates and deletes as they happen. Your app keeps writing to the old database the whole time, and you switch over when the new one has caught up.

It has rules, though, and every gotcha we hit was one of them.

The pre-flight checklist

We went through each of these before creating anything. Skip one and the migration stalls.

1. Logical decoding is on at the source. Postgres needs wal_level = logical to publish row changes. On RDS you get there with the rds.logical_replication parameter. Ours was already set, but check it, because changing it needs a reboot.

2. Every table has a primary key. The subscriber uses it to find the row an update or delete applies to. This query should return nothing:

SELECT c.relname
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind = 'r'
  AND NOT EXISTS (
    SELECT 1 FROM pg_index i
    WHERE i.indrelid = c.oid AND i.indisprimary
  );

3. The target already has the schema. Replication copies rows, not tables. We let our normal CI pipeline run all 204 migrations against the new database, so both sides had identical schemas.

4. The target tables are empty, with one exception you need to plan for. Because CI had already migrated the new database, its migration history table was full. Copying the old one on top would fail on duplicate keys. So we published every table by name and left that one out. If you use any migration tool that tracks history in a table, you'll have the same issue.

5. The new database can reach the old one. The subscriber opens the connection, not the other way round. Our RDS security group blocked it. We added the inbound rule in a separate security group so we could delete it cleanly afterwards, then tested the path with dblink before going further.

6. The target stays awake. Ours pauses with no client connections, and a replication stream doesn't count, so a tiny service pinged it every few seconds during the copy.

7. You know where the bytes are. Two tables held about three quarters of the data. The biggest was a log of webhook deliveries with no retention policy. A 30-day retention job before the copy would have saved a lot of waiting. We added it afterwards, naturally.

The SQL that did the work

Here's the condensed version. Hostnames and passwords are placeholders.

On the source, create a dedicated replication login and a publication that lists tables explicitly:

CREATE ROLE migration_repl WITH LOGIN PASSWORD '<password>';
GRANT rds_replication TO migration_repl;
GRANT USAGE ON SCHEMA public TO migration_repl;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO migration_repl;

DO $$
DECLARE t text;
BEGIN
  SELECT string_agg(quote_ident(tablename), ', ')
    INTO t
  FROM pg_tables
  WHERE schemaname = 'public'
    AND tablename <> '_prisma_migrations';
  EXECUTE 'CREATE PUBLICATION app_migration FOR TABLE ' || t;
END $$;

On the target, subscribe. This creates the slot on the source and starts the initial copy:

CREATE SUBSCRIPTION app_migration
  CONNECTION 'host=<source> dbname=app user=migration_repl
              password=<password> sslmode=require'
  PUBLICATION app_migration
  WITH (copy_data = true, create_slot = true);

Then watch three things: per-table state on the target, error counters on the target, and how much WAL the slot is holding on the source.

-- target: r = ready
SELECT srsubstate, count(*) FROM pg_subscription_rel GROUP BY 1;
SELECT apply_error_count, sync_error_count FROM pg_stat_subscription_stats;

-- source
SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn))
FROM pg_replication_slots;

All 82 tables reached ready the same day, with both error counters at zero.

Verifying without fooling yourself

Run ANALYZE on the target first. The initial copy doesn't leave planner statistics behind, and your first real queries will plan badly without them.

Then we used two checks. First, one query (through dblink) counted rows in every table on both sides and returned only the tables that differ. An empty result is the signal you want, and it's much easier to trust than scrolling through 82 matching numbers.

Second, an md5 over full rows for a few tables:

SELECT md5(string_agg(x::text, '|' ORDER BY id)) FROM "Organization" x;

Hashes matched on slow-moving tables and differed on two tables touched on every login, simply because the two queries ran seconds apart. Expect that, and don't panic.

The cutover: one merge, every connection

Our rule was that every service, and every connection path inside each service, switches in the same deploy. If one path moves and another doesn't, a service can write a row to one database and then fail to read it from the other.

We made that boring on purpose:

Days before, every service learned to read its connection string from a new secret name, falling back to the old one. No behavior change.
Minutes before, we created the new secrets. Running services don't pick them up until redeployed, so still no change.
We merged one pull request, and the deploy rolled every service onto the new database.

For a few minutes during the deploy, some services wrote to the old database and some to the new one. Forward replication kept carrying old-side writes across. A key collision would show up as an apply error (it stayed at zero). Two sides updating the same row would not show up anywhere, which is why we cared so much about keeping that window short. The last write to RDS landed seven minutes after the merge.

The rollback we kept for a week

This is the part we'd recommend most. After cutover, we turned replication around so the old database followed the new one:

Minutes before the merge, create a logical replication slot on the new database. It retains every change from that moment, so the rollback covers the cutover itself. Don't create it days early: an unread slot was holding roughly a gigabyte of WAL per hour for us.
Once the old side is quiet (we sampled its write counters for sixty seconds), drop the forward subscription.
Subscribe the old database to the new one from that slot with copy_data = false, since it already has every row, and origin = none, so only the application's own writes flow back instead of echoing the replicated ones.

Going back would have meant reverting one commit. After a week of daily row count checks, we dropped the reverse subscription (outside a transaction block, since a slot was attached), snapshotted RDS and shut it down.

The thing that bit us

Logical replication does not replicate schema changes. No ALTER TABLE, no DDL at all. While replication runs in either direction, every migration has to run on both databases.

We knew that. We had one CI migration job per database. But one of our cutover changes accidentally pointed the old database's job at the new one. Fifty-two minutes after cutover, a migration added three columns on the new side only, and the reverse stream stopped at the first row that used them. We applied the same SQL to RDS by hand about fifteen minutes later, and the stream caught up with nothing lost.

The lesson is boring and real: before changing a connection setting, list everything that uses it, including CI jobs.

If we did it again

We'd keep: tables published by name, a dblink connectivity test before subscribing, mismatch-only verification queries, one deploy for every connection path, and a reverse replication rollback.

We'd change: audit who uses each connection string first, and add retention to noisy tables before copying.

We also paired with an AI coding agent: it drafted every query and read the results, and a human ran every statement that touched production. That split worked well.

We wrote up the full story, with every SQL file and a step-by-step timeline, here on our blog. And if you want somewhere to practice this on a real database, managed Postgres hosting from Prisma has a free plan with no card. It covers Prisma Postgres with 200,000 operations a month and 2 GB of storage, plus Prisma Compute with 1M requests, 360 GB-hours of memory, 4 active vCPU-hours and 10 GB of outbound bandwidth a month.

Questions about any step? Ask in the comments.