You're the principal engineer advising on architecture for a new B2B SaaS product that will need complex multi-table transactions, strict data-residency guarantees for enterprise customers in the EU, and predictable infrastructure costs at a contracted scale of millions of requests/day. A junior architect proposes building the entire backend on Firebase/Firestore because 'it worked great for our last consumer app.' What's your reasoning for where BaaS composability breaks down here, and what would you recommend instead?

## Why the past success does not transfer The instinct 'it worked for our last app' is exactly the failure mode a principal engineer needs to catch, because BaaS composability is a fit for **a shape of problem** — simple access patterns, single-tenant or loosely related data, elastic consumer traffic — and this project has three requirements that sit outside that shape, each for a distinct technical reason. ## Transactional complexity **First, transactional complexity.** Firestore (and similarly Firebase's peers) supports transactions, but with real constraints: a transaction can touch a limited number of documents, must complete quickly, and retries automatically on contention, which works for 'update a document and a counter together' but breaks down for genuine multi-table, multi-entity business transactions — e.g., 'create an invoice, decrement inventory across three warehouse records, and post a ledger entry, all-or-nothing, potentially touching dozens of rows with complex constraint checks.' A relational database with real **ACID** transactions and foreign-key constraints is built precisely for this: the database engine enforces referential integrity and rolls back the entire operation on any failure, with no document-count ceiling and no need for the application to hand-roll optimistic-retry logic. Trying to force this onto Firestore means either: - restructuring the business transaction into an awkward sequence of smaller, non-atomic writes (opening a window for partial failures/data corruption), or - building a compensating-transaction saga pattern by hand — real distributed-systems engineering effort that a relational database would have given for free. ## Data residency **Second, data residency.** Enterprise EU customers commonly require contractual guarantees — often backed by a Data Processing Agreement and sometimes audited — that data is stored and processed only within specific EU regions, with no replication or backup crossing borders, and with logging/audit trails proving it. Most BaaS platforms let you pick a region for a project, but the guarantee that 'no data or metadata ever leaves that region, including backups, logs, and any managed sub-services the platform uses internally' varies significantly by vendor and by which managed features are enabled, and needs to be verified against the actual vendor contract and compliance documentation, not assumed from 'a region was picked in the console.' A principal engineer's job here is to insist on reading the vendor's specific compliance commitments (data residency addenda, sub-processor lists) against the customer contract's requirements before committing architecture — not to guess. ## Cost predictability at contracted scale **Third, cost predictability at contracted scale.** BaaS pricing is per-operation (per document read/write, per auth verification, per function invocation), which is attractive at low, spiky consumer traffic because it scales to zero. At a contracted millions-of-requests/day floor, that same model inverts: the company now has a known, large, sustained load, which is exactly the situation where reserved/provisioned capacity (a sized relational database instance, or DynamoDB provisioned capacity with savings plans) is both cheaper and, critically, budgetable — finance teams pricing a multi-year enterprise contract need to forecast infrastructure cost as a predictable line item, not a usage-metered variable that could spike with a client's unexpected traffic pattern or a batch job gone wrong. ## The recommendation, sliced by requirement Given all three, my recommendation is not 'abandon managed services entirely' but to be precise about which slice of the system each requirement applies to. - The **core transactional domain** — the invoicing/inventory/ledger logic with strict consistency and audit needs — belongs on a traditional relational database (e.g., Postgres) behind a real service layer that owns transaction boundaries explicitly, deployed in infrastructure where region and data flow are fully under contractual control, sized with provisioned/reserved capacity for cost predictability. - Meanwhile, genuinely **BaaS-shaped slices of the same product** — say, sending transactional emails, or handling non-sensitive user-preference storage that doesn't touch the residency-controlled domain — can still reasonably use managed services, because the composability and velocity benefits are real where the constraints don't bite. This hybrid approach is common in real enterprise architectures: the regulated, transactional core sits on owned or tightly-controlled infrastructure, while peripheral, low-stakes functionality is composed from managed services. ## The broader principle The broader principle a principal engineer should be applying, and teaching the junior architect, is that BaaS composability is a tool matched to a problem shape — elastic traffic, simple per-entity access patterns, no hard cross-border data constraints, correctness needs that tolerate eventual consistency — and reusing a past success uncritically means checking whether this problem still has that shape, rather than pattern-matching on 'it worked before.' The right question isn't 'can Firestore technically do this,' since with enough workaround engineering it often technically can, but 'does forcing this problem into Firestore's model cost more in workaround complexity, compliance risk, and unpredictable spend than building the transactional core properly would.'