[abuehrle]

Sorry I couldn't figure this out from the docs, but Stripe data is queried "live" from Stripe, right? The abstraction is great, but won't this lead to unexpected N API calls when joining across my domain + Stripe?

[kiwicopple]

Yes, the data is queried live.

> unexpected N API calls when joining across my domain

I'm not sure why they would be unexpected (because it should displace some other API calls). I'll hazard a guess that you're worried about fetching the same data multiple times? If that's the case, then yes, you should materialize the data into your database.

The Wrapper itself handles pagination, but you'd also want to make sure you're using filters & limits in your SQL statements.

[abuehrle]

Thanks for the reply. I'll flesh out my thought process in case it's helpful. My immediate reaction was excitement about the abstraction. An example use case is joining my users to their corresponding Stripe Customers in SQL. The kinds of queries I can reasonably write depend on implementation details of the connector. For example, if Stripe has a bulk customer lookup (list of customer IDs -> Customers), and the connector uses it, I can estimate I'd be able to query on the order of 500 Users at a time in a performant way. But if the API only supports looking up one customer at a time, that 500 User query kicks off 500 API requests, which isn't going to work.

You're right -- it's not unexpected -- maybe more like a leaky abstraction.

[ako]

Materialized views enable you to "cache" the response, and only refresh it periodically.

[chrisjc]

Wait, you're telling me that you can create materialized views using foreign tables in Postgres?

Is there a way to propagate changes from the foreign data source through the FDW to Postgres?

Or would it just be some kind of task polls the foreign data source pulling a delta?