| > I wonder why this wasn't built on top of, or an enhancement to, the existing (excellent) multicorn[1] project Have to agree with you there, multicorn is extremely cool. I'm a big sqlalchemy fan so their default SQLA wrapper was a killer feature to give up (although maybe we could do something similar with launchbadge/sqlx[1]). We investigated using multicorn early this year and had a few hiccups. Activity on the original repo[2] quieted way down ~3 years ago. For example, pg14 support hasn't landed and the newest supported python version is EOL in 2022. There is new fork[3] with pg14 support (15 in the pipe) that might pick up in adoption but thats still TBD. Supabase aims to support new major Postgres versions within 2-3 months so we have to be very careful taking on dependencies that might slow that process. > I'd love to understand more about the technical rationale that drove this. Architecturally, multicorn has postgres communicate with a separate python process on the host that does all the hard work. That's convenient, but it can bloat over time and/or be memory hungry for larger result sets. The rust implementation runs in-process and is generally a lot lighter. Currently I'd say supabase/wrappers is a safer/easier version of the C API vs a direct analog to multicorn. Over time I think we'll see that comparison become more appropriate. There's a lot of excitement around the concept internally and we've already been floating some ideas wrt `auto-mapping` tables for common SQL dialects, a generic JSON HTTP API wrapper, etc. Stay tuned! [1]https://github.com/launchbadge/sqlx
[2]https://github.com/Segfault-Inc/Multicorn
[3]https://github.com/pgsql-io/multicorn2 |