4 ms·

Congrats on the launch! Two questions: - How does this deal with specifics of the query languages of the different data stores? I'm not an expert with Snowfla

Congrats on the launch! Two questions: - How does this deal with specifics of the query languages of the different data stores? I'm not an expert with Snowflake, but I suppose it supports specific querying capabilities not found in Postgres' SQL dialect. How are those exposed to Hydra users? - I'm confused by "As soon as transactions are committed in Postgres, they are accessible for analytics in real-time" vs. "Recently committed transactions are moved from Postgres to Snowflake in near real-time". Is data propagated to Snowflake synchronously or asynchronously? I.e. is it guaranteed that data can be queries from Snowflake right the next moment after a transaction has been committed (as suggested by the former) or not (as suggested by the latter)? Disclaimer: I work on Debezium, another solution people use for propagating data from different databases (including Postgres) into different data sinks (including Snowflake)

wuputah 5y ago
Hi, JD here, Hydra's CTO. Thanks for the interest and questions! Today, queries need to be Postgres-compatible to be intelligently routed, but queries with specific query syntax or functions beyond Postgres can be routed with our manual router[1]. This is our first solution to this problem and plan to iterate in response to customer pain. Sorry for the confusion! Data moves asynchronously -- we're not trying to implement multi-phase commits -- but we can act on data very quickly once committed. Our solution here uses Postgres logical replication. Using the Data Bridge is optional and a customer's existing solutions are welcome as well. [1]: https://hydras-io.notion.site/Router-a91f5282f1354c54a9ba894864658e10 https://hydras-io.notion.site/Router-a91f5282f1354c54a9ba894...