That last one is great if it’s hidden behind a flag and some loud messages saying “failed to build, consider using —-python-only with performance limitation.”

Otherwise it’s going to be a source of mysterious performance issues with a single error message hidden somewhere in your CI or other logs.

I'm a bit mixed on a flag because C library dependencies are a fair support burden and an awful lot of people do not have workloads where a pure Python implementation is a significant performance issue because it's lost in the actual work done by the database.

I'd agree with something like a warning on first load or maybe something like an optional package so you could pin `psycopg3[cext]` if you want to guarantee the extension installed.

There is a mechanism to ensure that there is no unexpected regression. Exposing the PSYCOPG_IMPL env var a program can make sure to obtain a specific implementation and import fails if it's not available. https://www.psycopg.org/psycopg3/docs/api/pq.html

> - Asyncio from the ground up

> - Python only fallback if the C extension fails to build

These two are really big! The former, for first-party async support, making it much easier to use with async frameworks.

The latter would make it much easier to ship in containers. I assume it's still better use the C version, for performance reasons.

YES to this last!! Musl cross deploy can be annoying otherwise - any tips on building Alpine Linux ?