RelativeDB is an open source query engine built around the Relational Transformer architecture, developed by Stanford’s Tabular and Relational (STAR) Project. These models can adapt to new databases and prediction tasks using relatively little labeled context.
With some of my experiments, the results have been remarkable. On some tasks, RelativeDB can outperform XGBoost with only a small amount of relational context and no manual feature engineering.
So RelativeDB turns relational foundation models into something you can query (like this customer churn query):
``` PREDICT NOT EXISTS(orders.*) OVER (90 DAYS FOLLOWING) FROM customers ```
The engine finds the relevant context across the related tables and returns a prediction. The goal is to make questions like churn, demand forecasting, fraud detection, and recommendations feel more like database queries than bespoke ML projects.
Longer term, I think the optimizer should be able to choose between relational foundation models, fine-tuned models, and conventional approaches such as XGBoost depending on the query (how much graph-like context is needed vs just tabular features). Bridging ML to LLMs in a sane way.
I think there are markets for quantitive finance and utilizing emerging context graphs.
The project is early, and I would especially appreciate feedback on the query language and execution model.
RelativeDB: https://github.com/RelativeDB/RelQL Stanford RT-J: https://star-project.stanford.edu/rt-j/
As a busy techie with kids and other family obligations and my recent health diagnosis, I wanted an efficient way to integrate workouts in my daily routine and my research indicated that HIIT/Tabata style routines fit that requirement much better than a dedicated long running/planned workout routine.
I made a simple PWA to help me with that endeavor that I have found useful and hoping some of you may like it as well. No sign ups needed but you can sign in if you'd like to save custom presets and history/progress. You may also enjoy some of the fitness guides/blog posts that I am put together to help someone get started more easily. Built using javascript, vite and firebase.
Feedback is most welcome, both via the app/email or comments here.
There's a new Pokemon pack rip site every week now. What there isn't is a way for a store that already sells things to run this themselves, so I built one.
Recently I wasted several hours wrangling my dev environment only to find out that the browser frontend was talking to the wrong version of the backend. This got me thinking--why on earth are we still using simple numbers to describe which process to connect to? Why not use names instead? I thought of all the times a program wouldn't start because of port conflicts. The more I thought about it, the crazier it seemed.
Modern operating systems already offer no-conflict ports: if you make your TCP server listen on port 0, the OS assigns you a random available port. But that only solves half the problem.
I built the other half: PortZero. It's a GPLv3 program that watches for processes (and docker containers!) with a special PZ_TUNNEL environment variable:
PZ_TUNNEL=myapp-{branch}.portzero.local:80 npm run dev
1. Create a virtual NIC (if it hasn't already)
2. Create a new virtual IP address
3. Create a DNS record that substitutes things like {branch} based on the working directory of the process, and points at that virtual IP address
4. Start listening on that virtual IP address on the port of your choice (e.g. port 80 for http, port 443 for https, port 5432 for postgresql)
5. Forward any TCP connections to that virtual IP address / virtual port to the random, OS-assigned port that your process or container is actually listening on
The result is you don't have to think about ports anymore, you just have to think about subdomains. You can have multiple services available on port 80 without conflicts, as long as they have different portzero.local subdomains.
It does some other cool stuff like:
- Enable HTTPS on local HTTP services by creating a local CA and registering it on your machine
- Enable cloud tunnels so you can access your apps on other devices (paid feature)
Links: