[wuputah]

Hi! JD here, Hydra's CTO.

Hydra does not use FDWs except for Postgres-to-Postgres communication (for now). What we found was that FDWs do not do pushdown very well, even when Postgres has full information. You can get FDWs to push down aggregations, but complex queries with subqueries etc quickly get slow again. In short, our goal is to have your queries take full advantage of the power of each datastores, and we found that FDWs do not accomplish that goal.

We want to support GraphQL at some point, so same goes for us!

We are thinking about an OSS version, I think how we do "limited" is a big part of what that means. What would you like to see in an OSS version? What would you use it for?

[gavinray]

Thanks for the explanation =D

  > What would you like to see in an OSS version? What would you use it for?

I think that's a difficult question to answer because it's hard to do data-access partially. How do you gate that, so it doesn't give everything away for free and incentivizes people to still pay you?

Read-only access might be one way, but I'm unsure how popular that would be.

  > What would you use it for?

Generating GraphQL API's for other datasources by funneling them through Postgres

[zozbot234]

Parent comment is absolutely right that FDW as a general query router is still under heavy development. It's very likely that we'll see further improvement in forthcoming Postgres releases, which will come with additional benefits since FDW are used for a lot more than just "high-level" query routing in Postgres.

[gavinray]

This would be great.

I know that EnterpriseDB is heavily invested in FDW development and core Postgres stuff, so maybe we'll see some more neat stuff come out of that team that makes it upstream.

[tbrock]

In that case how does it work? Are the connectors wrappers around the other db drivers that expose a common Postgres wire protocol?