HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
MagicStack
asyncpg
Python2016–2024
MagicStack / asyncpg

asyncpg

A fast PostgreSQL Database Client Library for Python/asyncio.

23Distinct people
29Mentions
0Explicit recommenders
8.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A fast PostgreSQL Database Client Library for Python/asyncio.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year29 dated mentions

Observed mentions: 2016-07-19 09:54:11 UTC to 2024-08-18 21:22:19 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 3 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC633
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC514

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
asyncpg -- A fast PostgreSQL Database Client Library for Python/asyncio asyncpg is a database interface library designed specifically for PostgreSQL and Python/asyncio. asyncpg is an efficient, clean implementation of PostgreSQL server binary protocol for use with Python's asyncio framework. You can read more about asyncpg in an introductory blog post. asyncpg requires Python 3.9 or later and is supported for PostgreSQL versions 9.5 to 19. Other PostgreSQL versions or other databases implementing the PostgreSQL protocol may work, but are not being actively tested. Documentation The project documentation can be found here. Performance In our testing asyncpg is, on average, 5x faster than psycopg3. The above results are a geometric mean of benchmarks obtained with PostgreSQL client driver benchmarking toolbench in June 2023 (click on the chart to see full details). Features asyncpg implements PostgreSQL server protocol natively and exposes its features directly, as opposed to hiding them behind a generic facade like DB-API. This enables asyncpg to have easy-to-use support for: prepared statements scrollable cursors partial iteration on query results automatic encoding and decoding of composite types, arrays, and any combination of those straightforward support for custom data types Installation asyncpg is available on PyPI. When not using GSSAPI/SSPI authentication it has no dependencies. Use pip to install: $ pip install asyncpg If you need GSSAPI/SSPI authentication, use: $ pip install 'asyncpg[gssauth]' For more details, please see the documentation. Basic Usage import asyncio import asyncpg async def run(): conn = await asyncpg.connect(user='user', password='password', database='database', host='127.0.0.1') values = await conn.fetch( 'SELECT * FROM mytable WHERE id = $1', 10, ) await conn.close() asyncio.run(run()) License asyncpg is developed and distributed under the Apache 2.0 license.
Read the full README on GitHub

What Hacker News says

29 sources
Does the celery SQLAlchemy broker support PostgreSQL's LISTEN/NOTIFY features? Similar support in SQLite would simplify testing applications built with celery. How to add table event messages to SQLite so that the SQLite broker has the same features as AMQP? Could a vtable facade send messages on tablet events? Are there sqlite Triggers? Celery > Backends and Brokers: https://docs.celeryq.dev/en/stable/getting-started/backends-... /? sqlalchemy listen notify: https://www.google.com/search?q=sqlalchemy+listen+notify : asyncpg.Connection.add_listener sqlalchemy.event.listen, @listen_for psychopg2 conn.poll(), while connection.notifies psychopg2 > docs > advanced > Advanced notifications: https://www.psycopg.org/docs/advanced.html#asynchronous-noti... PgQueuer.db, PgQueuer.listeners.add_listener; asyncpg add_listener: https://github.com/
Read the rest
In Show HN: PgQueuer – Transform PostgreSQL into a Job Queue
nbrad·Jan 27, 2024Submission

Ask HN: Is Python async/await some kind of joke?

Returning to Python full-stack development after a stint with Node, it seems like using async/await is not widely adopted enough in the Python ecosystem to actually use? In no particular order - Django doesn’t have an async ORM? (https://docs.djangoproject.com/en/5.0/topics/async/) - Django Rest Framework has no async support? https://github.com/encode/django-rest-framework/issues/7260 - SQLModel’s section on async support basically says “docs coming soon”? Yet this is designed to be used with FastAPI? Why would the docs not start with async/await? https://sqlmodel.tiangolo.com/advanced/ - SqlAlchemy/asyncpg => you can’t use it if you’re using PgBouncer (necessary most of the time with Postgres) in transaction mode? What?? https://github.com/MagicStack/asyncpg/issues/1058 - Ubiquitous “requests” library used in most docs examples, no asyn
Read the rest
c support https://github.com/psf/requests - Top package for GitHub REST API, no async support https://github.com/PyGithub/PyGithub - …on and on… What’s the point of my nice FastAPI server if nothing internally can use async/await? How is everyone else doing this? /rant
8 points · Open discussion
what a great post, we have had a ton of issues with users using pgbouncer and it's not because things are "broken" per se, it's just the situation is very complicated, and pgbouncer's docs are also IMO in need of updating to be more detailed and in a few critical cases less misleading, specifically the prepared statements docs. This blog post refers to this misleading nature at https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html#pre... . > PgBouncer says it doesn’t support prepared statements in either PREPARE or protocol-level format. What it actually doesn’t support are named prepared statements in any form. IMO that's still not accurate. You can use a named prepared statement just fine in transaction mode. start a transaction (so you aren't in autocommit), use a named statement, works fine. you just can't use it again in anot
Read the rest
her transaction, because it will be "gone" (more accurately, "unmoored" - might be in your session, might be in someone else's session). Making things worse, when the prepared statement is "unmoored", its name can then conflict with another client attempting to use the same name. so to use named prepared statements, you can less ideally name them with random strings to avoid conflicts, or you can DEALLOCATE the prepared statement(s) you used at the end of your transaction. for our users that use asyncpg, we have them use a uuid for prepared statements to avoid these name conflicts (asyncpg added this feature for us here: https://github.com/MagicStack/asyncpg/issues/837). however, they can just as well use DEALLOCATE ALL, set this as their `server_reset_query`, and then so that happens in transaction mode, also set `server_reset_query_always`, so that it's called at the end of transactions. Where pgbouncer here IMO entirely misleadingly documents this as "This setting is for working around broken setups that run applications that use session features over a transaction-pooled PgBouncer." - which is why nobody uses it, because pgbouncer claims this is "broken". It's not any more broken than it is to switch out the PostgreSQL session underneath a connection that uses multiple transactions. Pgbouncer can do better here and make this clearer and more accommodating of real world database drivers.
In PgBouncer is useful, important, and fraught with peril
There aren't any special "bulk" interfaces at the moment, you can load data via a small program using our language bindings (INSERT in a loop). We'll add support for batched `executemany()` soon to cater to very large loads specifically. A similar optimization in asyncpg [1] led to a 10x improvement in throughput (~100Krec/sec per connection), and we expect similar performance from EdgeDB once the protocol and the bindings are updated. Loading arbitrary JSON by introspecting the data, and auto-generating the schema and the necessary DML statements is fairly straightforward too. I have a rough Python proof-of-concept, will need to find time to finish and publish it. [1] https://github.com/MagicStack/asyncpg/pull/295
In EdgeDB: EdgeQL
Related to ORMs/queries/performance, I have found the following combination really good: * aiosql[0] to write raw SQL queries and having them available as python functions (discussed in [1]) * asyncpg[2] if you are using Postgres * Map asyncpg/aiosql results to Pydantic[3] models * FastAPI[4] Pydantic models become the "source of truth" inside the app, they are designed as a copy of the DB schema, then functions receive and return Pydantic models in most cases. This stack also makes me think better about my queries and the DB design. I try to make sure each endpoint makes only a couple of queries. Each query may have multiple CTEs, but it's still only a single round-trip. That also makes you think about what to prefetch or not, maybe I want to also get the data to return if the request is OK and avoid another query. [0] https://github.com
Read the rest
In 12 requests per second: A realistic look at Python web frameworks
Agreed. I will never recommend an ORM, things simply spiraled out of control for medium to large-ish projects that had more than 2 developers. Even with "best practices", code ended up having a mix of raw SQL and ORM-style queries, and it was hard to reason about the code. Since switching to asyncpg [0] these problems have vanished. It commands a deeper knowledge of actual SQL, but I would argue this knowledge is absolutely necessary and one of the disadvantages of an ORM is that it makes the SQL that is eventually run opaque. Not sure if there are equivalents to asyncpg for other RDBMS's. [0]: https://github.com/MagicStack/asyncpg
In Migrating to SQLAlchemy 2.0
the psycopg2 driver for PostgreSQL supports an async mode which uses PostgreSQL's full blown non-blocking API, this is what I used when I did my tests and might be what was used here. There is also the asyncpg driver that is native to PG's non-blocking API. PG is the one database that does lend itself to async because it has a fully non-blocking client library available. https://www.postgresql.org/docs/12/libpq-async.html https://www.psycopg.org/docs/advanced.html#green-support https://github.com/MagicStack/asyncpg
In Django Async: What's new and what's next?

Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.