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