Turning PostgreSQL Into an Integration Engine

I wanted to see how far PostgreSQL extensibility could go.

Most People Think PostgreSQL Is Just a Database, but PostgreSQL is actually a programmable system. With extensions and procedural languages, it can do far more than simply store and retrieve data.

Recently I started thinking about a simple idea:

What if PostgreSQL could call REST APIs directly from SQL queries?

Instead of always relying on a backend service to act as an integration layer, some interactions with external systems might happen directly from the database.

This idea led me to run a small technical experiment.

Project Idea

In most architectures today, integrations usually look like this:

Database → Backend Service → External API

The backend service is responsible for calling APIs, processing responses, and storing results in the database.

But PostgreSQL has something many people forget: extensibility.

It supports:

• procedural languages (PL/Python, PL/pgSQL, etc.)
• native extensions written in C
• custom SQL-callable functions

This raises an interesting possibility:

Could PostgreSQL itself perform HTTP requests?

If that is possible, SQL queries could potentially interact with external services during execution.

Technical Possibility

PostgreSQL allows developers to extend the database with custom functions.

These functions can be implemented using:

• procedural languages (Python, Perl, etc.)
• native extensions written in C

That means we can implement a function capable of performing HTTP requests and expose it directly to SQL.

Conceptually, the goal is to enable something like this:

SELECT http_request(
    'httpbin.org',
    443,
    '/headers',
    'GET',
    NULL,
    '{"Authorization":"Bearer demo-token"}'::jsonb,
    true,
    30
);

This query sends an HTTPS request to an external endpoint and returns the response to the SQL session.

Because headers are passed as JSON, they can also be dynamically constructed inside SQL queries.

3. Experiment & Result

To explore the idea, I implemented two different versions of the HTTP function.

Experiment 1 — PL/Python Implementation

The first version uses PL/Python, one of PostgreSQL’s supported procedural languages.

Using Python inside PostgreSQL makes it relatively easy to perform HTTP requests using common Python libraries.

Example usage:

select http.post('https://httpbin.org/post','{"data":{"a": 1,"b": 2}}');

The query triggers an HTTPS request and the response is returned to the SQL client.

To simplify experimentation, this version was packaged as a Docker image with PostgreSQL and PL/Python preconfigured.

Experiment 2 — Native PostgreSQL extension

The second experiment goes deeper by implementing the HTTP functionality as a native PostgreSQL extension written in C.

Extensions written in C integrate directly with the PostgreSQL engine and offer more control over performance and behavior.

This version explores how HTTP capabilities could potentially be embedded closer to the database layer.

Example usage:

SELECT http_request(
    'httpbin.org',
    443,
    '/headers',
    'GET',
    NULL,
    '{"Authorization":"Bearer demo-token"}'::jsonb,
    true,
    30
);

Development Process

Another interesting aspect of this experiment was the development workflow.

I intentionally used AI-assisted development (or what I like to call vibe coding) while building the project, especially when working with PostgreSQL extension code in C.

AI helped accelerate:

• extension scaffolding
• exploration of low-level C patterns
• rapid prototyping
• documentation

It was interesting to see how AI could help speed up systems-level experimentation, not just application development.

Design Considerations

Allowing a database to call external APIs raises several architectural considerations.

Latency

Database queries are expected to be fast and predictable.
External API calls introduce network latency, which can slow down query execution.

Transaction Behavior

If an HTTP request is executed inside a transaction, the transaction might be blocked while waiting for the external service.

Reliability

External APIs can fail, timeout, or become unavailable.
Proper timeout handling and error management are essential.

Security

Allowing outbound HTTP requests from the database may introduce security concerns, especially if unrestricted endpoints are allowed.

Because of these considerations, this approach should not replace backend services in most production architectures.

However, it can still be useful for:

• experimentation
• rapid integration prototypes
• certain data enrichment scenarios

Final Thoughts

This experiment started with a simple question:

Can the database participate directly in integration workflows?

PostgreSQL’s extensibility makes it a surprisingly powerful playground for exploring ideas like this.

And with modern AI-assisted workflows, experimenting with systems-level concepts has become significantly faster.

I’m still exploring how far the idea of database-driven integrations can go.