Sponsoring this project will help achieve swift completion and ensure the maintenance of psycopg2, psycopg3 and other related projects.
If you use Python and PostgreSQL, and you would like to support the creation of the most advanced adapter between the two systems, please consider becoming a sponsor. Thank you!
Psycopg is released under the terms of the GNU Lesser General Public License, allowing use from both free and proprietary software.
- Check the features list to see what Psycopg offers
- Read the Psycopg documentation. Be sure to check the Frequently Asked Questions
- Install Psycopg!
For help requests and development discussions please subscribe to the mailing list email@example.com.
Psycopg 2.9 has been released!
This is a relatively small release compared to previous major releases. However the creation of the packages took a lot of effort. The previously used CI system now has reduced support for free software projects - it was decided that package building should be moved to GitHub Actions.
Packaging has also become more complex because of the evolution of the Python packaging standards and the need to support multiple architectures (Intel, ARM, PPC...).
Maintaining a project such as Psycopg requires a lot of effort. For this reason, we are extremely grateful to all our sponsors who are enabling the maintenance and development of Psycopg. Thank you very much!
The psycopg2 pool is a pretty simple object, little more than... a pool of open connections, and I think it falls short in several ways:
- the top usability problem is the fact that it cannot be used as context manager;
- if a connection is broken it is not noticed it until it is used by a client;
- if minconn connections are already taken, a new one is created and disposed of as soon as finished using, regardless of whether other clients may need it;
- if more than maxconn connections are requested the client will receive an error.
For psycopg3 I would like something better. I have read around, looking into other pool implementations to figure out what a well designed connection pool ought to do (a very well thought one seems the Java HikariCP) and these are a few ideas I'd like to work on: they are here for a feedback, before I jump into enthusiastically implementing the wrong thing...
The adaptation system between Python objects and PostgreSQL types is at the core of psycopg2 and psycopg3. The flexibility of the psycopg2 adaptation system provides good out-of-the-box object mapping and allows users to customise it to suit any need. Do you want your decimal numbers returned as float because you need speed over pennies? Do you want to map PostgreSQL Infinity dates to the 25th of December 3099? That's certainly doable.
The psycopg3 adaptation system needs some modification compared to psycopg2, because psycopg3 uses the "extended query protocol" to send query parameters separately from the query. Together, with the differences to accommodate, there is also a chance to improve a system that has been in use for several years and has shown its shortcomings together with its strengths.