pg_net: Async Networking
The pg_net API is in beta. Functions signatures may change.
pg_net enables PostgreSQL to make asynchronous HTTP/HTTPS requests in SQL. It differs from the http
extension in that it is asynchronous by default. This makes it useful in blocking functions (like triggers).
It eliminates the need for servers to continuously poll for database changes and instead allows the database to proactively notify external resources about significant events.
Enable the extension#
- Go to the Database page in the Dashboard.
- Click on Extensions in the sidebar.
- Search for "pg_net" and enable the extension.
http_get
#
Creates an HTTP GET request returning the request's ID. HTTP requests are not started until the transaction is committed.
Signature #
This is a Postgres SECURITY DEFINER function.
Usage #
http_post
#
Creates an HTTP POST request with a JSON body, returning the request's ID. HTTP requests are not started until the transaction is committed.
The body's character set encoding matches the database's server_encoding
setting.
Signature #
This is a Postgres SECURITY DEFINER function
Usage #
http_delete
#
Creates an HTTP DELETE request, returning the request's ID. HTTP requests are not started until the transaction is committed.
Signature #
This is a Postgres SECURITY DEFINER function
Usage #
Analyzing responses#
Waiting requests are stored in the net.http_request_queue
table. Upon execution, they are deleted.
Once a response is returned, by default, it is stored for 6 hours in the net._http_response
table.
The responses can be observed with the following query:
The data can also be observed in the net
schema with the Supabase Dashboard's SQL Editor
Debugging requests#
Inspecting request data#
The Postman Echo API returns a response with the same body and content as the request. It can be used to inspect the data being sent.
Sending a post request to the echo API
Inspecting the echo API response content to ensure it contains the right body
Alternatively, by wrapping a request in a database function, sent row data can be logged or returned for inspection and debugging.
Inspecting failed requests#
Finds all failed requests
Configuration#
Only Self-Hosted Deployments can Modify Configuration Variables
See the self-hosting docs for self-hosting instructions.
The extension is configured to execute up to 200 requests per second reliably. The response messages are stored for only 6 hours to prevent needless buildup. The default behavior can be modified by rewriting config variables.
Get current settings#
Alter settings#
Note, that doing ALTER SYSTEM
requires SUPERUSER but on PostgreSQL >= 15, you can do:
Then variables can be changed:
Then reload the settings and restart the pg_net
background worker with:
Examples#
Invoke a Supabase Edge Function#
Make a POST request to a Supabase Edge Function with auth header and JSON body payload:
Call an endpoint every minute with pg_cron#
The pg_cron extension enables PostgreSQL to become its own cron server. With it you can schedule regular calls with up to a minute precision to endpoints.
Execute pg_net in a trigger#
Make a call to an external endpoint when a trigger event occurs.
Send multiple table rows in one request#
More examples can be seen in the Extension's GitHub page
Limitations#
- To improve speed and performance, the requests and responses are stored in unlogged tables, which are not preserved during a crash or unclean shutdown.
- By default, response data is saved for only 6 hours
- Can only make POST requests with JSON data. No other data formats are supported
- Intended to handle at most 200 requests per second. Increasing the rate can introduce instability
- Does not have support for PATCH/PUT requests
- Can only work with one database at a time in PostgreSQL. It defaults to the postgres database.
Resources#
- Source code: github.com/supabase/pg_net
- Official Docs: github.com/supabase/pg_net