wrappers VS postgresql_faker

I used one of their open source work in a project: https://github.com/supabase/wrappers

It’s appreciated since SaaS on AWS is a no-no in my field.

I’m currently playing with PostgreSQL, foreign data wrappers, and pgrx rust extensions. My development experience has been surprisingly smooth and enjoyable.

My main issue is that joins will be processed locally, so all the foreign data will be fetched before the join happens. But otherwise basic CRUD is easy.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

https://github.com/pgcentralfoundation/pgrx

https://github.com/supabase/wrappers

However, considering the emergence of Supabase wrappers, it might be more beneficial to develop a walkthrough focused on creating Rust-based wrappers. This way, the community can start building a variety of useful wrappers (really plugins).

We're experimenting with including tables connected to external data sources using Supabase Wrappers https://github.com/supabase/wrappers as a way to link external APIs into the GraphQL schema but that work is in an early stage. That approach would be limited to the Stripe, Firebase and S3 for now though

This would be an ideal use case for a postgresql foreign data wrapper. See more here: https://github.com/supabase/wrappers/

> On a sidenote, is not the wrappers for Airtable, BigQuery and ClickHouse opensourced? Or why did they skip that column in the second table?

All of the wrappers are open source. You can see the source for the Airtable, BigQuery, and ClickHouse wrappers here https://github.com/supabase/wrappers/tree/5fac8afb62e6e8362b...

The `self-hosted` column is only missing from the "under development" wrappers in the blog post's table because those are not production ready and shouldn't be self hosted (yet).

> What you have listed is not an actual solution, just a list of things you'd need to solve it

Sorry. HN comments is a narrow channel and so I elected not to try to squeeze a full-blown actual solution through it.

> I could say the only thing you need for the DSL to SQL solution is a programming language, my list would be one item

Well...I enumerated the features of the language I'm using just as you could enumerate the features of your programming language. My list could have one item just as easily as yours can: "PostgreSQL DDL"

> how to test this is a valid question as well

My answer to that question has been to use pgTAP for testing and postgresql_faker to generate synthetic data

https://pgtap.org/

https://gitlab.com/dalibo/postgresql_faker

> My tests also don't require a database to with data in it to test

No, but they do require a runtime, be it in Scala or whatever. That's no different from my case where my test runtime is an ephemeral PostgreSQL database.

> Do you have an example of how this works if you are performing joins between tables?

You bet.

https://asciinema.org/a/629243

> Does every table need to have some sort of user id in it directly for that to work?

It's common for single-database multi-tenant data models to add something like a "tenant_id" to every table. It's simple, more efficient, and more foolproof. You can however just join to other tables in the policy condition as I have done. Extra care should be taken as discussed in the PostgreSQL docs:

https://www.postgresql.org/docs/current/ddl-rowsecurity.html