When does Fivetran stop being the right choice for a growing ingestion footprint?

## Frame the question correctly "Build vs buy" invites a religious answer. The useful frame is a **portfolio decision per source**, revisited as volumes change. Most mature data platforms end up mixed: a managed service handling dozens of low-volume SaaS sources nobody wants to own, and a small number of high-volume or constrained pipelines handled differently. ## What you are buying, precisely A managed connector removes: source API churn, incremental state management, backfill logic, retry/resume, destination DDL for schema changes, and the on-call burden for all of it. That is real, recurring, unglamorous work with no competitive value. For a five-person data team with thirty SaaS sources, buying it is close to unarguable — thirty hand-written extractors is a full-time job that produces nothing a customer would pay for. ## Axis 1: volume and the cost curve Consumption priced per changed row scales with source churn. That curve is friendly for a marketing platform with tens of thousands of changed rows a month and unfriendly for a production database table with hundreds of millions. The asymmetry matters: a handful of tables typically dominate the bill. The correct response is surgical, not wholesale. Measure per-connector and per-table consumption. If three tables account for most of the spend, evaluate moving *those three* to self-hosted log-based capture and leave the other forty alone. Wholesale migration off a managed service to save money on a minority of the footprint usually costs more in engineering time than it saves, and it re-acquires all the maintenance you were paying to avoid. Also price the alternative honestly. Self-hosted ingestion is not free: compute, storage, on-call, upgrade toil, and the engineer-months to reach parity on retry, backfill and schema handling. Compare loaded cost to loaded cost, including the failure modes you will now own at 3am. ## Axis 2: coverage and the custom-source share The value of a connector catalog is proportional to how much of it you use. A team whose sources are all standard SaaS gets enormous leverage. A team whose sources are increasingly internal microservice APIs, partner feeds in bespoke formats, or legacy systems gets less: you are writing connector code anyway, now inside someone else's framework and lifecycle. Track the ratio of catalog-connector sources to custom ones over time — a rising custom share is the leading indicator that the economics are shifting. ## Axis 3: constraints the service cannot satisfy Some requirements are not negotiable with a vendor: - **Residency and sovereignty.** Data that must not leave a jurisdiction, or must not transit a third-party processor at all. - **Network reachability.** Sources inside a private network with no acceptable path for a hosted service, or a security posture that forbids one. - **Latency.** Managed EL is scheduled batch at heart. If a consumer genuinely needs seconds, a streaming capture pipeline is the right architecture regardless of cost. - **Semantics.** If you need exactly the change stream — every intermediate state, ordered — a loader that syncs current state on a schedule is the wrong tool no matter how well it is operated. When a constraint like this appears, the decision is architectural rather than financial, and cost arguments are a distraction. ## Axis 4: lock-in and exit cost The practical lock-in of a managed EL service is moderate but real: destination table shapes, bookkeeping columns, and every downstream model written against them. Reduce it deliberately — keep transformation logic in your own repository and warehouse, avoid embedding vendor-specific columns deep in business logic, and know what a migration would actually cost before you need to make the argument. A vendor relationship you cannot price your way out of is a governance problem, not just a cost one. ## How to actually run the decision 1. **Instrument first.** Per-source consumption, per-source freshness requirement, per-source incident count. Most teams argue this from anecdote because they never measured it. 2. **Segment the portfolio.** Sort sources by cost and by constraint. Look for the small set that dominates. 3. **Cost the alternative properly.** Engineer-months to parity, then ongoing operations. Include the on-call you re-acquire. 4. **Pilot narrowly.** Move one high-cost source and measure real total cost for a quarter before extrapolating. 5. **Re-evaluate on a schedule.** Volumes grow, pricing changes, connectors mature. A decision made at one scale is not a decision for all time. ## The answer that impresses It is not "buy, because engineering time is expensive" or "build, because the bill is outrageous". It is a candidate who says: here is how I would measure it, here is the shape of the cost curve, here is the small set of sources where the trade flips, and here is what I would deliberately keep managed even while insourcing the expensive tail — plus an honest account of what insourcing re-acquires. ## Version note Pricing models, plan structures and self-hosted alternatives all move; treat any specific comparison as time-bounded and re-derive it from measured usage rather than from a remembered rate card.