Show HN: I implemented a neural network in SQL(github.com)
github.com
Show HN: I implemented a neural network in SQL
https://github.com/xqlsystems/xarray-sql/blob/claude/xarray-sql-mnist-demo/benchmarks/nn.py
21 comments
I don't want to rain on discovering a genuinely cool bit of theory, but it's not "new" per se.
The equivalence with Einstein summation was noted in this paper [0]. Sandia labs wrote an SQL database based around graphBLAS called TenSQL a few years back. And something similar to your idea of relational algebra as the basis for AI had a paper published earlier this year [1], naming it Tensor Logic.
If you want to stick to the full relational model, you might be interested in Differential Dataflow [2].
[0] https://arxiv.org/html/2510.12269v3
[1] https://arxiv.org/html/2601.17188v1
[2] https://github.com/TimelyDataflow/differential-dataflow
The equivalence with Einstein summation was noted in this paper [0]. Sandia labs wrote an SQL database based around graphBLAS called TenSQL a few years back. And something similar to your idea of relational algebra as the basis for AI had a paper published earlier this year [1], naming it Tensor Logic.
Are all of these common operations secretly relational, just with the wrong data model?
If you want to stick to the full relational model, you might be interested in Differential Dataflow [2].
[0] https://arxiv.org/html/2510.12269v3
[1] https://arxiv.org/html/2601.17188v1
[2] https://github.com/TimelyDataflow/differential-dataflow
In the past platforms have integrated ML algorithms into relational databases and SQL through extensions (both commercial and open source). A famous open source one was MADlib [1], which has an implementation of neural networks. Even the commercial ones were similar, I used ML algorithms in SQL Server many years ago around 2005 I think.
I am wondering about.. SQL as a declarative structured query language that can be optimized into essentially any kind of distributed, directed acyclic graph of processing - vs the special characteristics of relational databases (relational algebra, relvars, etc. etc.) is an important distinction as - of yet, I see the author linking both together so I'm trying to understand what it is about relational structures that specifically helped here (just not seeing it yet, not that it isn't there).
Also, wondering if ISO/IEC 9075-15:2023 SQL standard for multidimensional arrays (MDA) is of any use here? Paper describing SQL/MDA here [2].
[1] https://madlib.apache.org/documentation.html
[2] https://www.ifis.uni-luebeck.de/~moeller/Lectures/WS-19-20/N...
I am wondering about.. SQL as a declarative structured query language that can be optimized into essentially any kind of distributed, directed acyclic graph of processing - vs the special characteristics of relational databases (relational algebra, relvars, etc. etc.) is an important distinction as - of yet, I see the author linking both together so I'm trying to understand what it is about relational structures that specifically helped here (just not seeing it yet, not that it isn't there).
Also, wondering if ISO/IEC 9075-15:2023 SQL standard for multidimensional arrays (MDA) is of any use here? Paper describing SQL/MDA here [2].
[1] https://madlib.apache.org/documentation.html
[2] https://www.ifis.uni-luebeck.de/~moeller/Lectures/WS-19-20/N...
I need to better understand your first question before I can comment. In theory, we could work with MADlib too -- what we do is port scientific data, which typically is a "tensor" or Nd array, into a tabular view. I believe you know relational theory better than I do, I am still fairly new to the field.
WRT ISO/IEC 9075-15:2023: This is the standard established from rasdaman, IIUC. I reject this approach (which treats arrays as a column type), and instead adopt one inspired by Michael Stonebraker's SciDB (which treats arrays as tables themselves). For an in depth review of the topic, I recommend this NSF paper: https://par.nsf.gov/servlets/purl/10545560
WRT ISO/IEC 9075-15:2023: This is the standard established from rasdaman, IIUC. I reject this approach (which treats arrays as a column type), and instead adopt one inspired by Michael Stonebraker's SciDB (which treats arrays as tables themselves). For an in depth review of the topic, I recommend this NSF paper: https://par.nsf.gov/servlets/purl/10545560
I've been working on something similar, implementing a relational language on top of a tensor library[0].
Mathematically, einsum and database joins are the same thing, just over different semirings (real numbers for einsum, booleans for databases). A lot of papers about datalog explore this sort of thing in more depth. In particular, Dyna[1] might be interesting.
[0]: https://arxiv.org/abs/2509.22614 [1]: https://dyna.org/
Mathematically, einsum and database joins are the same thing, just over different semirings (real numbers for einsum, booleans for databases). A lot of papers about datalog explore this sort of thing in more depth. In particular, Dyna[1] might be interesting.
[0]: https://arxiv.org/abs/2509.22614 [1]: https://dyna.org/
Somewhat more reliable than implementing SQL in neural networks.
I have done similar as well: https://github.com/seanwevans/pg_gpt2
I'll try it next time I've got Greece vacation money
It did seem cross-posted from LinkedIn
Can you maybe give a bottom line about this? It sounds like a nice little toy demo, which would be a fun thing in itself, but then you suggest it could be somehow state of the art? It would be nice if you could present the information necessary for the reader to decide on the feasibility of this instead of just dropping the repo link and a wall of text.
I'm just going to go back to making my CRUD endpoints...
Jokes aside, sounds really impressive, though I only understood about 10% :D
Jokes aside, sounds really impressive, though I only understood about 10% :D
I read all that and there wasn't even a recipe at the end!
Seriously though, sounds cool, but way over my head.
Seriously though, sounds cool, but way over my head.
Neat! Feels analogous to "X runs Doom" demos (but NN).
Just today I saw this implementation of DOOM in SQLite using a recursive CTE for a simple ray tracer: https://github.com/petergpt/doomql
Totally. I can’t wait to take this to https://hytradboi.com
Fable is impressed.
initially rolled my eyes at "neural networks in SQL," but after reading the code I came away impressed
basically it comes down to using relational algebra as the IR, letting a database optimizer reason about tensor programs
basically it comes down to using relational algebra as the IR, letting a database optimizer reason about tensor programs
I would have had the same gut reaction as you lol.
You’re spot on. I think that SQL, as a data oriented and logic PL, might be ideal for writing tensor programs.
You’re spot on. I think that SQL, as a data oriented and logic PL, might be ideal for writing tensor programs.
With down time on a warm beach during a heatwave, cool salty water giving me fresh ideas, I had an idea: what if we used Coiled's Geospatial benchmark discussion as a comprehensive overview of geo and climate queries. Are all of these common operations secretly relational, just with the wrong data model? Using Claude Code on the beach, I can confirm that this seemed to be the case: Claude and I publish a benchmark that illustrated how every common operation in geo and climate sciences (at the 100 TB range) were actually secretly relational operations: https://github.com/xqlsystems/xarray-sql/blob/main/docs/geos....
Most surprisingly of all, from these examples was that a core operation, regridding, was just a sparse matrix-vector product. Claude had pointed out to me that in this data model, matmul was just a `SUM(val * val) ... JOIN .. GROUP BY`. This has a direct parallel to einsum notation, but can be expressed in (arguably) elegant SQL syntax! This capability seemed to be greater than the sum of it's parts.
Back in the cool water of the Ionian, I thought about the implications of this more deeply. I reflected that, all of the Coiled benchmarks did, deep down, was _post process_ simulations that happen in numerical/array code. Why couldn't these physics calculations be push down into the database also, if we could so matmul in SQL? Then it hit me: maybe they could, if in addition to linear algebra, if SQL could do calculus! https://bsky.app/profile/al.merose.com/post/3mpbods7wts2y
Later on, I implemented autograd on top of DataFusion's visitor pattern based on JAX's implementation. In my simplified array model, it turns out that we only care about partial differentiation on the diagonal of the Jacobian, meaning that `grad()`, `jvp` and `vjp` are just row-wise operations! I then implemented a common physics calculation from the coiled benchmark that required gradients. From here, I realized if I can autograd in the database, why can't I create a neural network?
As I came back home, I created some slides, and presented this work to DataFusion's inaugural showcase: https://www.youtube.com/watch?t=1511&v=5o-4hL8vGPw&feature=y... I realized in this synthesis that SQL is not necessarily a toy language for writing neural networks, but in fact, may be highly desirable in the future due to the fundamental principles of relational databases: the logical layer should be independent from the physical layer. If that property holds, and a neural network is a series of relations, could we create a SOTA distributed system for training more easily? For example, if we had one global logical plan of dataflow, could we better distribute work on 1000+ GPUs?
Several scientists and engineers and I are working together to explore this weird world of relational arrays at https://xql.systems (discord link at the bottom if you want to get involved).