MAmarklit·Jul 30, 2025Submission
2 points · Open discussionpramsey
pgsql-http
C2018–2025
pramsey / pgsql-http
pgsql-http
HTTP client for PostgreSQL, retrieve a web page from inside the database.
11Distinct people
11Mentions
0Explicit recommenders
1.6KGitHub stars
What to know before exploring
What it is
HTTP client for PostgreSQL, retrieve a web page from inside the database.
GitHub
Where it is used
No documented product use has been verified yet.
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 year11 dated mentions
Observed mentions: 2018-05-02 15:55:43 UTC to 2025-07-30 08:01:06 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
11 sourceshttps://github.com/pramsey/pgsql-http
It works well with Supabase, I tried it, its decent but you should only use it for endpoints you trust because waiting for the request is blocking.
If you want the requests to be async you need to use pg_background extension with it
In How to run cron jobs in Postgres without extra infrastructureThis only works as admin, use https://github.com/pramsey/pgsql-http instead. Whether or not you should, is a different question, there is a certain "oh no" factor to this.
In The time keepers: pg_cron and pg_timetableThe OP didn't write about a UI and we don't know what their needs are, so for all we know they're writing a Python-based back-end API in REST or GraphQL which is being consumed by a mobile UI or a SPA UI in React or Vue.js or whatever, such that that back-end API doesn't have to provide a UI. If the existing Python back-end doesn't provide a UI then any proposed substitute--including one in SQL--shouldn't have to provide a UI either, just an API. In that case, there are some ready-made solutions already available:
- PostgREST (https://postgrest.org/): REST API for PostgreSQL
- PostGraphile (https://www.graphile.org/) GraphQL API for PostgreSQL
- pg_graphql (https://github.com/supabase/pg_graphql) GraphQL API for PostgreSQL
- Hasura (https://hasura.io/) GraphQL API for various databases
If you want to blend data from a web API and you're
Read the rest
content with GraphQL, for some use-cases (not all, but some), there are options:
- Apollo Federation (https://www.apollographql.com/apollo-federation/)
- GraphQL Mesh (https://the-guild.dev/graphql/mesh)
- Hasura Remote Schema (https://hasura.io/blog/tagged/remote-schemas/)
If you want more control over the web API and you were going to fetch the data within your Python back-end and process it there, for some use-cases (not all, but some), there are options:
- pg_http (https://github.com/pramsey/pgsql-http)
Life is about trade-offs. Doing the work in SQL is not without its drawbacks, but it's also not without its benefits, and that's true for doing the work in a general-purpose language as well. Whatever the drawbacks of doing it in SQL, one of the benefits has got to be eliminating the impedance mismatch (for people who regard that mismatch as a problem, and the OP seems to be one such person). What I claim is that doing the work directly in the database shouldn't be ruled out in general (the specifics of a given use-case may rule it out in particular) any more than the other common patterns (API hand-written in Python, for instance) shouldn't be ruled out in general.
Couldn't you implement this in "pure" SQL by using psql-http https://github.com/pramsey/pgsql-http (from Crunchy ) for the webservice calls to OpenAI API?
In What's Postgres got to do with AI?Pgsql-HTTP: HTTP client for PostgreSQL
4 points · Open discussionLike pgsql-http?
https://github.com/pramsey/pgsql-http
In Supabase Wrappers: A framework for building Postgres foreign data wrappersthere are some great projects that present an http api for postgres that you could use with CRDB I think. I'm thinking of something like https://github.com/pramsey/pgsql-http
In How we built a serverless SQL databaseI did something similiar, but directly from postgresql triggers: https://github.com/pramsey/pgsql-http
You just have to be careful with failing queries and set timeout to low.
In Show HN: Skor – Drop-in microservice to get Postgres changes as JSON webhooks