apointoo.
Request access
HIPAA

Firestore for HIPAA Data: What a Database Proof Must Test

cmsapointoo··7 min read

Short answer: A Firestore database proof must test query completeness, transactions, tenant authorization, exports, backups, restore, location, and server-side access before a migration decision. As of 2026-08-15, Google Cloud publishes Firestore pricing, location behavior, and covered-product scope. A BAA or database label does not prove that application and administrative paths enforce the intended boundary.

GCP service fit and regional boundary

Firestore is a candidate only after the data contract survives a vertical-slice proof. Google Cloud’s HIPAA page describes covered products and shared responsibility. Firestore Locations describes database location. Firestore Pricing describes reads, writes, storage, indexes, and backups. Those sources support a bounded technical evaluation, not a claim that the database is approved for every application use.

List the actual queries: tenant membership, intake, booking state, idempotent outbox, report, export, and support lookup. Record query filters, ordering, indexes, transaction boundaries, expected cardinality, and failure behavior. A document model can be attractive for a Mongo-like workload, but a migration still changes query semantics, reports, constraints, and recovery.

Decide location before creating the database. Firestore location is a foundational choice. Match Cloud Run, files, keys, logs, backups, queues, and support policy to the tenant home zone. Do not add protected records to a database whose location or backup behavior is not approved.

Proof area Question Pass evidence
Queries Do all required reads return complete, scoped results? Query parity and negative tests
Writes Do transactions and retries preserve state? Idempotency and failure tests
Authorization Do server and client paths enforce membership? Denied access matrix
Recovery Can export, backup, and restore be controlled? Isolated restore evidence

Compare Firestore Rules and Admin SDK, Firestore location immutability, and Cloud SQL PostgreSQL RLS.

Request, data, key, and identity path

Server-side membership must authorize every protected read and write. Client Firestore Security Rules govern client SDK paths, but a server using Admin SDK or another privileged path still needs application membership checks. Resolve tenant and home region server-side. Do not trust a document path or client-supplied tenant field as proof.

Model documents so the authorization context is visible and testable. A tenant path can support a rule, but an export job, scheduled report, Admin SDK worker, backup, restore, and support tool may not use the client path. Test each identity and operation. A successful client read is not evidence for server-side access.

Keep the stored data minimum necessary. Generic event type, time, currency, value, and an opaque internal reference may support an approved conversion workflow. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising destinations. Store additional fields only when the customer contract and risk analysis justify them.

authenticated request
  -> server membership and home region
  -> Firestore query or transaction
  -> authorized document scope
  -> redacted audit and queue event

Jobs, audit, backup, and failure handling

Database proof needs adversarial paths. Create two synthetic tenants and run client reads, server reads, writes, updates, deletes, transactions, batches, reports, exports, backup, restore, and support actions. Attempt wrong-tenant path substitution, missing membership, expired identity, changed region, and a privileged Admin SDK call.

Transactions and retries require measured behavior. Run a failure after one write, a duplicate event, a partial batch, an unavailable dependency, and a timeout. Compare resulting documents with the source contract. Confirm that idempotency keys do not leak across tenants or create duplicate outbound events.

Inspect logs, indexes, errors, backup metadata, and exports. Do not copy full documents into logs. Test restore in an isolated project or database, reapply membership, verify location and keys, and delete the synthetic copy. A provider backup feature is not proof that the restored application is authorized.

Cost is part of proof. Reads, writes, index entries, storage, backups, traffic, and named databases can change the estimate. Run representative queries and record current pricing assumptions. Do not use free-quota arithmetic as a production guarantee.

Cost and proof gate

Choose Firestore only when query and tenancy proof pass together. Use Firestore Pricing for current request, storage, index, and backup inputs. Add Cloud Run, logs, keys, secrets, backups, support, and regional duplication. Label numbers as estimates with workload, region, and date.

  • Freeze source query and transaction contracts.
  • Build one vertical slice with synthetic tenants.
  • Test client, server, Admin SDK, export, restore, and support roles.
  • Measure reads, writes, indexes, storage, backups, and retries.
  • Keep a PostgreSQL fallback if proof or margin fails.

Firestore proof checklist

Do not approve a database from a happy-path demo.

  1. Create synthetic tenant A and tenant B records.
  2. Run every required query and compare completeness with the current contract.
  3. Test wrong-tenant reads and writes through client and server paths.
  4. Run transaction, batch, retry, export, backup, and restore tests.
  5. Inspect Admin SDK roles, logs, keys, location, and support access.
  6. Measure current cost assumptions and record the date.
  7. Obtain counsel and customer approval before protected migration.

The final decision should name missing queries, unproved privileged paths, and any data-location exception. If the database cannot prove the contract, choose another design or defer the migration.

Build the proof from the current source contract. List each collection, document, index, query, transaction, report, export, backup, restore, role, and event. For every item, write expected result for tenant A, expected denial for tenant B, retry behavior, audit field, location, retention, and cost input. If a query is not expressible or requires a broad Admin SDK path, mark it as a migration gap.

Run parity checks with synthetic data that includes empty results, duplicate events, concurrent updates, deleted records, pagination, time ranges, report filters, and failed dependencies. Compare record counts, state transitions, and idempotency with the existing contract. A query that works for one document can fail when an index, report, or export changes the scope.

Review Firestore Rules and server identity independently. Client tests should prove Rules behavior. Server tests should prove membership, tenant, region, role, and collection scope. Restore tests should install policies before reading. Support and export tests should use separate roles. Do not let a provider feature list substitute for these checks.

Cost proof should use measured representative operations. Count reads, writes, index entries, storage, backups, retries, exports, logs, keys, Cloud Run calls, and regional resources. Recalculate when query shape or tenant count changes. Keep a PostgreSQL fallback for contracts that require relational constraints or database-enforced row policy.

The final gate should name what passed, what failed, what remains application-enforced, and which legal or contract question is open. It should not call Firestore compliant because a sample read and write succeeded.

Frequently asked questions

Do Firestore Rules protect Admin SDK reads?

Do not assume that. Server-side Admin SDK access is a privileged application path and still needs membership, tenant, role, and export controls.

What is the most important migration test?

Run a complete vertical slice with real query shapes, transactions, wrong-tenant denials, retries, reports, exports, backups, and restore. A single document demo is not enough.

Does Firestore pricing prove the database is affordable?

No. Add indexes, storage, backups, logs, keys, traffic, regional resources, support, and migration work. Recalculate using measured queries and current provider rates.

When should PostgreSQL be tested?

Test it when the workload needs relational reporting, constraints, transactions, or database-enforced row policies. Compare contracts and proof results rather than choosing from price alone.

References

Related articles