apointoo.
Request access
HIPAA

RDS PostgreSQL vs DynamoDB for a Protected Booking Store

cmsapointoo··9 min read

Short answer: RDS PostgreSQL and DynamoDB solve different protected-booking problems. PostgreSQL offers relational constraints, transactions, flexible queries, and a place to evaluate database-enforced row policies. DynamoDB offers access-pattern-first design and request-based pricing. As of 2026-08-15, AWS publishes separate pricing pages for both, while 45 CFR 164.312 describes technical safeguard objectives. Neither database removes the customer’s authorization and evidence work.

AWS service fit and regional boundary

The correct store is the one that preserves the required data and access contracts with the smallest unproved surface. AWS RDS for PostgreSQL pricing reflects an instance and storage operating floor. DynamoDB pricing reflects requests, storage, and indexes. The difference is not only a bill. It changes how a team expresses tenant access, reporting, transactions, backups, and operational recovery.

Start with the workload’s questions: read one booking outcome, list recent events, reconcile an opaque reference, mark an idempotent state, produce a report, export an approved tenant set, and restore after an incident. If the workload needs joins, foreign keys, flexible filters, and multi-record transactions, PostgreSQL may reduce rewrite risk. If the workload has stable key-value access patterns and event records, DynamoDB may reduce idle infrastructure. Both still need a server-side tenant boundary.

Regional policy is independent of engine. Record home region, database location, keys, logs, backups, queues, and support access. Do not use a database choice to imply residency or regulatory approval. The AWS HIPAA eligible service reference can support service scope, while the customer’s configuration and risk analysis support the deployment claim.

Concern RDS PostgreSQL DynamoDB
Access shape Relational queries and transactions Known keys and indexes
Tenant backstop Database row policies can be evaluated Keys and identity conditions remain explicit
Cost floor Instance and storage while provisioned Requests, storage, indexes, and backups
Rewrite risk Schema and SQL conversion Access-pattern and denormalization conversion

Read DynamoDB tenant partitioning and LeadingKeys conditions before accepting a key-value design. Compare the cloud-wide boundary in cloud shared responsibility for HIPAA.

Request, data, key, and identity path

Both stores need the same trusted identity sequence. Authenticate the caller, resolve membership and home region server-side, authorize the operation, then execute the database request. Do not let a browser-supplied tenant or region select the row policy, SQL predicate, DynamoDB key, or connection. A wrong-tenant request must fail before a useful record is returned.

PostgreSQL can use a session tenant context and row-level policy as a backstop, but the application still needs membership and role checks. Test privileged roles, connection pooling, migrations, reporting users, exports, and background jobs. A policy that only applies to one web connection does not cover a batch role or a superuser path.

DynamoDB needs a key and identity design for every operation. Prefixes can organize tenant records, while IAM conditions can narrow some operations. They do not automatically cover scans, exports, backups, restores, or administrative access. A migration plan should list each operation and its expected denial.

Keep data minimum necessary in either store. A generic conversion record can carry approved event type, time, currency, value, and an opaque reference if counsel and the tenant approve it. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or free-text notes to an advertising destination. The database contains a controlled source record; the outbound event is a separate disclosure decision.

caller
  -> membership and tenant resolution
  -> authorization and minimum fields
  -> PostgreSQL policy or DynamoDB key and condition
  -> data operation
  -> audit event without full record

Queue, audit, backup, and failure handling

The database comparison is incomplete without alternate paths. Test queue consumers, scheduled reports, exports, support tools, migration jobs, backup operations, restore environments, and analytics readers. PostgreSQL policies may be bypassed by an owner or privileged role. DynamoDB conditions may not constrain an operation that is not modeled for them. Both engines can leak through logs and failed requests.

Use two synthetic tenants. Run point read, list, update, delete, batch, transaction, index, report, export, and restore tests. For PostgreSQL, test a missing tenant context, a connection reused across tenants, a privileged reporting role, and a direct database client. For DynamoDB, test key substitution, mixed batches, Scan, index queries, and a role with missing condition context.

Transactions carry different proof burdens. PostgreSQL can enforce multiple relational changes in one transaction, but the application must still select the right tenant rows. DynamoDB transactions can combine items, but the application and key policy must ensure that mixed-tenant operations are intended and authorized. Idempotency and retry behavior should be tested after partial failure.

Backups should be encrypted, region-approved, access-controlled, and restored in an isolated environment. Verify that restored data cannot be read by a tenant role before membership and policy setup. Keep audit data narrow and review retention from risk, contract, and operational requirements. A working backup is not proof that every backup operator has minimum access.

Cost and proof gate

Compare total operating assumptions, not a single unit price. AWS RDS pricing should include instance hours, storage, backups, monitoring, networking, and high availability. DynamoDB pricing should include reads, writes, indexes, storage, backups, logs, and traffic. Both estimates need region, workload shape, retrieval date, and exclusions.

Engineering cost can dominate. PostgreSQL migration may require schema conversion, query rewrites, connection pooling, migration scripts, and operational procedures. DynamoDB migration may require a full access-pattern inventory, denormalized records, new indexes, report pipelines, and different transaction logic. A cheap monthly number does not make a large untested rewrite cheap.

  • Choose PostgreSQL when relational constraints and a database policy backstop are load-bearing.
  • Choose DynamoDB when access patterns are stable and the team can prove every operation.
  • Separate application, database, support, backup, and restore identities.
  • Price migration, tests, recovery, and review alongside provider charges.
  • Recheck AWS service eligibility and current pricing before commitment.

Decision proof checklist

Do not select an engine until one vertical slice passes. Use synthetic tenant membership, intake, booking state, an outbox event, and one report.

  1. Write the access and transaction contract for the slice.
  2. Implement both candidates with tenant membership resolved server-side.
  3. Run wrong-tenant, missing-context, privileged-role, export, restore, and support tests.
  4. Reconcile record counts, idempotency, query results, and audit evidence.
  5. Measure operational work, storage, requests, backups, and restore time.
  6. Review region and contract boundaries with counsel before protected data.

The decision should record what the selected database proves, what remains application-enforced, and what is deferred. A database product, BAA, encryption setting, or price tier is not a compliance certificate. It is one input to a risk-managed design.

The migration decision should preserve the current product contract before optimizing the provider bill. Take one vertical slice and write down record states, query results, transaction boundaries, idempotency, report fields, export scope, and restore behavior. Implement that slice in both candidates with synthetic tenants. Measure engineering changes and operational steps, not only monthly resources.

PostgreSQL proof should include connection pooling, row policy context, privileged roles, migrations, reports, and restore. DynamoDB proof should include keys, indexes, batches, transactions, Scan, exports, and restore. Both need queue, log, key, backup, support, and offboarding checks. If a result differs, treat it as a contract gap rather than quietly changing the application.

Cost should be a range with assumptions. State region, availability, storage, backup, query volume, index count, traffic, logs, support, and migration labor. Recheck current pricing before a commercial decision. The Aurora Serverless cost review is relevant when a relational option uses an elastic capacity model. A cheaper request line can still carry a larger fixed or verification cost.

Use the same acceptance tests for both candidates. Confirm that tenant membership is checked before reads and writes, that missing context denies, that retries are idempotent, and that reports, exports, backups, and restores preserve scope. For PostgreSQL, inspect policies, connection pooling, privileged roles, views, and migrations. For DynamoDB, inspect keys, indexes, batches, transactions, scans, and separate operator paths.

Record query and transaction gaps instead of hiding them in a compatibility layer. If a database change requires a broad service role, new copy, or unreviewed report job, the migration has increased proof burden. If the product needs relational constraints, flexible reporting, or database policy, use that requirement to guide the choice. If it needs predictable key-value access and elastic request cost, prove that scope instead.

Include recovery and offboarding in the cost model. A database with low request cost can still require more backup, restore, export, or support work. A relational instance can have an always-on floor but reduce custom authorization and reporting code. The decision should show recurring cost, one-time migration, owner time, and test cadence.

Before protected data, get the customer and counsel decision on the data and contract boundary. Do not claim that either database, an AWS agreement, encryption, or a pricing tier establishes compliance. The evidence supports a scoped architecture choice only.

Frequently asked questions

Is PostgreSQL always safer than DynamoDB?

No. PostgreSQL can offer useful database policy and relational controls, but privileged roles and application paths still need review. DynamoDB can be suitable for stable access patterns when identity, keys, operations, and bypasses are tested.

Which option is cheaper?

It depends on region, workload, availability, storage, backups, logs, and migration effort. RDS has an instance floor. DynamoDB charges by requests and storage, but reports and indexes can add work and cost.

What is the critical DynamoDB test?

Run wrong-tenant reads and writes across point operations, indexes, batches, transactions, Scan, exports, backups, and restores. A passing primary query does not prove alternate operations are narrow.

No. It can be a technical backstop. The customer still needs role mapping, agreements, risk analysis, minimum necessary handling, incident response, and counsel review.

References

Related articles