Neural Networks in SQL: A Geek Experiment That Reveals Deep Learning's Core Principles

When Databases Meet Deep Learning

For most developers, training a neural network means Python, PyTorch, TensorFlow, and rows of GPUs. SQL is typically relegated to the "back office" — querying and storing data. But a project shared on Hacker News has completely upended that assumption: a developer implemented a fully functional neural network using nothing but SQL.

The project, titled "Show HN: I implemented a neural network in SQL," didn't generate a massive discussion, but it raises a fascinating question: neural networks are fundamentally matrix operations, and SQL can express relational algebra and aggregate computations — so is it actually possible to implement forward propagation, and even backpropagation, in pure SQL? The answer is yes — though the process is genuinely painful.

It helps to first understand the mathematical nature of neural networks: they are a series of nested composite functions. Each layer performs a linear transformation (matrix multiplication plus a bias vector), followed by a nonlinear activation function (such as Sigmoid or ReLU). This repeated cycle of "linear transformation + nonlinear activation" is what gives neural networks the ability to approximate arbitrarily complex functions. Crucially, this structure is naturally decoupled from any specific programming language — any computational system that supports matrix operations and basic math functions can, in theory, serve as a neural network implementation substrate. SQL is an extreme test of that proposition.

Why Implement a Neural Network in SQL?

A Valuable Thought Experiment

From an engineering standpoint, training a neural network in SQL has almost no production value — it's slow, hard to debug, and lacks an automatic differentiation toolchain. But the point of projects like this isn't practicality. It's about stripping away framework abstractions and confronting the underlying principles directly.

The core computations of a neural network can be broken down into these fundamental operations:

• Matrix multiplication: multiplying inputs by weights, corresponding to SQL's JOIN + GROUP BY + SUM
• Activation functions: Sigmoid, ReLU, etc., expressible via SQL's built-in math functions or CASE WHEN
• Gradient computation: the chain rule in backpropagation, requiring deeply nested subqueries or recursive CTEs
• Parameter updates: iterative weight updates, relying on UPDATE statements or recursive queries

When you're forced to express these operations in the language of set algebra, you reach a new level of understanding of the mathematical essence of neural networks.

SQL's Expressive Power Is Vastly Underestimated

Modern SQL — especially dialects that support recursive CTEs and window functions, like PostgreSQL — is theoretically Turing complete, meaning any computable logic can be expressed in it. This isn't obvious: SQL was originally designed as a declarative, set-oriented query language, and its Turing completeness was only formally established with the introduction of WITH RECURSIVE syntax in the SQL:1999 standard.

The WITH RECURSIVE syntax provides critical support for iterative training — each training iteration can be viewed as a recursive unfolding, progressively converging toward a trained model. From a computational theory perspective, recursive CTEs give SQL the ability to express "fixed-point computation": starting from initial weights, repeatedly applying gradient descent rules until the loss function value no longer changes significantly. This is semantically equivalent to a while loop in an imperative language — just expressed very differently.

Technical Challenges of Implementing Neural Networks in SQL

Expressing Matrix Operations Relationally

In SQL, matrices are typically modeled as triple tables: (row, col, value). This representation essentially unfolds a dense matrix into a sparse relation, with each matrix element corresponding to one row in the table. Multiplying two matrices involves joining on the shared dimension and summing:

SELECT a.row, b.col, SUM(a.value * b.value) AS value
FROM matrix_a a
JOIN matrix_b b ON a.col = b.row
GROUP BY a.row, b.col;

This snippet is essentially a complete matrix multiplication. Mathematically, matrix multiplication $C = A \times B$ computes each element as $C_{ij} = \sum_k A_{ik} \cdot B_{kj}$, which maps directly to SQL's "JOIN on dimension k and SUM the products" pattern. As the network gains more layers, these queries must be chained together, and complexity balloons rapidly while readability plummets.

Backpropagation: A Declarative Language's Nightmare

Forward propagation is manageable. The real challenge is backpropagation. To appreciate why, it helps to understand how modern deep learning frameworks handle gradient computation.

Frameworks like PyTorch use Automatic Differentiation (Autograd): during the forward pass, the framework quietly builds a computational graph, recording every tensor operation and its inputs and outputs. When you call loss.backward(), the framework traverses the graph in reverse, automatically applying the chain rule to each node to compute partial derivatives of the loss with respect to each parameter. The entire process is transparent to the user and requires just one line of code.

In SQL, all of this magic must be reconstructed by hand. Gradients need to be propagated backward layer by layer, and each layer's gradient depends on the results from the layer above it. For a network with $N$ layers, you need to build $N$ levels of nested subqueries or $N$ intermediate temporary tables — and the SQL for each one requires manually deriving the partial derivative formula for that layer. In an imperative language this is just a few lines of a loop, but in declarative SQL, code volume grows linearly with depth and maintainability deteriorates sharply.

This is exactly why projects like this are often described as "it works, but no one would want to maintain it" — they prove feasibility while clearly exposing SQL's inherent limitations for iterative numerical computation.

The Real Value of Projects Like This

Educational Value Far Exceeds Engineering Value

Bringing a neural network "down" to the SQL level means stripping away every abstraction that deep learning frameworks provide. Without the one-click magic of loss.backward(), developers must manually derive and write out every gradient formula. This "build from scratch" experience is profoundly illuminating for understanding automatic differentiation, computational graphs, and the mechanics of backpropagation — something that reading papers alone can't replicate.

Specifically, when you're manually writing gradient expressions for each layer in SQL, you gain a visceral appreciation for something: the chain rule isn't an abstract mathematical symbol — it's a concrete data flow. Upstream gradients multiply local derivatives at the current layer, and the result flows downstream. This kind of "understanding through code" tends to be far more durable than reading formulas in isolation. Many experienced researchers have built their intuition for deep learning systems through exactly this kind of "manual implementation" exercise.

Practical Implications for In-Database Machine Learning

"Doing machine learning inside a database" is not purely a geek joke. In-Database ML is an engineering direction that has attracted considerable attention in recent years. Its core logic is to bring computation to where the data lives, thereby reducing the overhead and latency of moving data around.

MADlib is an Apache open-source In-Database ML library that can execute linear regression, logistic regression, random forests, and other algorithms directly within PostgreSQL and Greenplum, without exporting data to external systems. BigQuery ML allows users to train and deploy machine learning models inside Google's data warehouse using standard SQL syntax, supporting linear models, XGBoost, and even imported TensorFlow models for inference. Cloud data warehouse solutions like Redshift ML and Snowflake ML Functions have followed suit.

The engineering value of these approaches is clear: when business data already lives in a database, running model inference or even training directly inside the SQL engine avoids round-tripping terabytes of data between storage systems and compute clusters, significantly reducing latency and infrastructure costs. This geek experiment, in a sense, previews the extreme form of this trend — compressing every component of a deep learning framework into a SQL engine.

The Geek Spirit: Using the "Wrong" Tool to See the Truth

The Hacker News community celebrates projects like this precisely because they embody pure curiosity — not for profit, not for efficiency, but simply to verify "can this actually be done?" Similar experiments — "implementing GPT in Excel," "detecting prime numbers with regular expressions" — together form a distinctive culture of experimentation in the tech world.

These seemingly "useless" attempts often yield unexpected cognitive breakthroughs. When you re-implement a complex system with a completely unsuitable tool, you're actually more likely to see its essential structure. This phenomenon has grounding in cognitive science: when familiar tools are replaced, the brain can't rely on ingrained operational habits and is forced to re-examine the mathematical meaning of every step — building a deeper conceptual understanding in the process.

Summary

Implementing a neural network in SQL is a thought experiment about the boundaries of technology. It won't replace PyTorch, and it won't appear in any production environment — but it clearly reminds us: neural networks are, at their core, mathematics, and mathematics can be expressed in any Turing-complete language.

For developers who want to deeply understand the underlying principles of deep learning, rebuilding familiar algorithms with unfamiliar tools may be one of the most direct learning paths available. The next time you call model.fit(), take a moment to consider: if you only had a SQL engine, where would you even begin?