POSTGRESQL · APACHE MADLIB · TEACHING LAB

Move computation
to the data.

A model can learn where the rows already live. Select a safe configuration, inspect its SQL, and let PostgreSQL execute MADlib inside the database.

Connecting…

TRADITIONAL ML

Database↓ exportNetwork↓ transferPython / pandas↓ fitModel

Rows cross process and network boundaries before training begins.

IN-DATABASE ML

PostgreSQL↓ SQL callApache MADlib↓ in placeModel

Computation stays close to storage; only compact results return.

01 · DATASET EXPLORER

Three questions, three data shapes

Inspect types, target, features and ten sample rows before choosing.

02 · SAFE MODEL BUILDER

Choose intent; the server chooses safe SQL

There is no SQL console. Every table, column, function and model name comes from a server-side whitelist.

GENERATED SQLVisible before execution

-- Select a dataset, features and algorithm.

This SQL runs the machine learning algorithm inside PostgreSQL.

03 · MODEL EVIDENCE

Turn a new observation into SQL

-- Prediction SQL appears here.

—

05 · K-MEANS EXAMPLE

Segments are coordinates, not customer personas

Cluster 1

Younger, frequent visits, high spending score.

Cluster 2

Mid-career, balanced income and engagement.

Cluster 3

Higher income, fewer visits, lower spending score.

For runtime safety, PostgreSQL orchestrates the bounded iterations while MADlib computes every squared point-to-centroid distance. These are teaching interpretations; inspect scale, distance and domain context before naming real segments.

06 · WHY IN-DATABASE ML?

Watch output stay small while rows grow

—Rows processed

—Execution time

—Browser transfer

—Estimated raw export

Traditional approach

SELECT *
FROM madlib_lab.student_performance;

Database → network → application → ML library

The complete relation leaves the database boundary.

In-database approach

SELECT madlib.logregr_train(...);

PostgreSQL → MADlib → model evidence

A compact command goes in; compact model output comes back.