(question) cohabitation with postgres_scanner ?

[laurentperez]

Hi

We have some projects using ATTACHed postgres instances thru https://github.com/duckdb/postgres_scanner.

I understand pg_duckdb brings 🦆 to postgres. We run pg instances on our metal and can freely install such an extension. I'm considering going this route, refactoring our attached pgs to use the extension instead, but doubts remain.

I'm confused because I don't understand if I should assume postgres_scanner is going to be deprecated in favor of pg_duckdb.

• will both options coexist or will the scanner be deprecated in favor of the extension ?
• will the extension transition at some point a paid option for pg sysadmins or will it remain free as in OSS ?

We now have 2 options to glue with postgres - which is a good thing, don't get me wrong ;) - and I'm not sure I understand if either option 1 (postgres_scanner) or option 2 (pg_duckdb) are intended to be mutally exclusive or not.

ty

[Tishj]

pg_duckdb is a Postgres extension that contains duckdb, allowing duckdb to interface with postgres with very little overhead, as it lives inside the server process.

The duckdb postgres_scanner extension allows any duckdb instance (whether it's the CLI, the python client, node client or any other client) to read from and interact with postgres.

I think these are vastly different capabilities, so I don't think there is any need to deprecate one in favor of the other.
A lot of the logic related to the postgres<->duckdb transformation layer can be shared between the two[1] which is nice, and can result in the cost of implementing feature X into the postgres_scanner being much smaller when X is already implemented in pg_duckdb, and vice versa

[1] not exactly, as the protocol used is different, internal c extension API vs libpq