Ask the source before copying the data

Imagine a support screen that needs one answer: has this order been paid? The payment system has the answer. An integration team proposes copying every payment record into a second database, keeping the copy current, and reading the copy when the agent opens the order. This is a hypothetical operational example, not the analytical use case in the cited demonstration.

That might be necessary. First ask whether the screen only needs one authorized answer now.

A technical demonstration of cross-cloud analytical queries shows a query across existing data sources without first building a permanent copy of the source table in the destination. The same demo materializes a joined table, showing that remote access and copying can coexist within one workflow. This is a real product capability, not a promise that an analytical query service is suitable for an operational payment-status screen or that data never moves during execution. Google Cloud’s federated-query documentation explains that some external-query results temporarily move into the query service. The distinction that matters is between a permanent synchronized replica and a bounded read for a specific question.

Decide from the consumer’s job

There are two different requests hidden inside “connect these systems.” One asks, “What does the source say now?” The other asks, “What state must the destination hold so it can act later?”

For the support screen, a scoped read can return an order status and its observation time. The source remains the authority. If the source is down, the screen should say the current status is unavailable or clearly label a cached answer. A second copy would create a new question: which status wins when the two disagree?

Source of truth current status

Scoped query authorized read observation time

Consumer one answer

A consumer asks a source for one current answer through an authorized scoped query; the query may process transient data without creating a durable replica.

For an abandoned-cart campaign, the destination may need to act without someone opening a screen. It may need a timely event, a consent state and a way to cancel a queued message after purchase. A live read at campaign time might still help, but a mere answer on demand is not the whole job.

Consumer needs	First design to test	Principal tradeoff
One current answer	Scoped query to the owner	Depends on source access and latency
Continuous action on change	Event or minimal delta sync	Must handle delay, duplicates and missed events
Historical decision evidence	Versioned snapshot of the relevant fields	Must govern retention and access
Operation during source outage	Explicit cache or replica	Can be stale; needs an age rule

This is a decision table, not a benchmark. No universal query-versus-copy threshold follows from it.

A copy has a continuing cost

The first extraction is easy to underestimate because it ends. The copy keeps living. A new field appears, an identifier merges, a permission changes, or an old event arrives after a new one. Now the destination can hold an answer the source would reject.

The cost is not only storage. It is reconciliation: monitoring lag, replaying missed changes, deleting data when required, and explaining why a decision used yesterday’s value. Those tasks are justified when the destination needs independent state. They are sorting when the only deliverable is a current answer.

A query has costs too. It can place load on the source, expose fields to another principal, cross a network boundary and fail at the worst moment. Query planners may process more data than the visible result suggests. The federation documentation describes execution details worth checking before treating a remote query as zero movement.

The safe query has a narrow purpose and a narrow result. Name the field owner. Restrict the caller’s permission. Decide how old an answer may be, how long the query may wait and what the interface says on timeout. Keep the observation time with the answer.

When a controlled copy earns its cost

“Local data gives us a predictable interface and fewer remote failures.” That is a serious argument. If the workflow has a hard latency requirement or must continue through a source outage, a controlled replica may be the right design.

The word controlled does the work. Define which fields are copied, how quickly they must update, what happens when updates stop, and when the consumer refuses to act on stale state. Test a late correction as well as the happy path. A fast stale answer can be worse than a visible unavailable one.

Start with the smallest consumer question. If a read solves it, keep the source in charge. If an action needs local state, copy only what that action can justify.

A small trial can settle the choice without building a general replication layer. Pick one question the consumer actually asks, record how fresh its answer must be, and run an authorized query against the source. Observe latency, source load and failure behavior with realistic access controls. Then try the narrowest copied state that would satisfy the same consumer. Compare not just response time but correction, deletion and outage behavior. The integration planning guide supplies the broader workflow context; this trial chooses where an answer should live. Neither path is automatically cheaper when the continuing maintenance is counted.

A connection is not measured by how many rows crossed it.