A model over your database: forecasts without training, time series and search in Postgres

NVIDIA released a model that makes predictions from a relational database without training for the task, IBM combined four time series models into one ensemble, and TigerData open-sourced a search library that works inside PostgreSQL. The common thread: a company's data already sits in a database, and the questions "what happens next" and "what happened back then" can be asked of it directly. For a business owner, the bar for a demand or churn forecast has dropped to one database with history.

What came out

On October 21, NVIDIA presented Kumo Relational on the Hugging Face blog. The model reads tables, foreign keys and timestamps and answers a predictive query, for example which customers will leave or how many units will sell. No training for the task and no manual feature engineering. On 41 tasks across 15 databases it beat trained models and gradient boosting pipelines. For a forecast the model takes only events before the cutoff date, so it doesn't peek into the future. The code and weights are open.

On October 22, IBM Research described a Granite ensemble for time series in the same place. Four pretrained models with different architectures each make a forecast, and the recipe combines them into a median and quantiles. By default all four models have equal weight, and nothing is fine-tuned. The 0.1 and 0.9 quantiles give an interval with a nominal coverage of 80%. It was tested on 97 GIFT-Eval configurations without fine-tuning.

On October 20, TigerData open-sourced searchgres.js, a TypeScript library under Apache-2.0: one PostgreSQL query combines BM25 keyword search, vector search, and filters by hierarchy, metadata and time. The example from the article: a power plant operator selects half an hour on a chart where output dropped and asks whether it was planned. The search finds the dispatch instruction and the shift log for that unit and time. Filters are applied before ranking, so the right record doesn't fall out of the top twenty.

Two days later, on October 22, the same team told how it built three memory systems for its Slack agent. A list of facts turned out too thin. A general knowledge graph with free access to SQL turned out too free: agents spent dozens of turns on database mechanics instead of the task. A tree on the ltree extension gave every record a place and a clear set of operations. The most expressive system wasn't the most useful one.

On October 14, Weaviate described PathSeer, a filtered vector search algorithm from a SIGMOD 2026 paper by Tsinghua University. In the authors' implementation, throughput is 1.2 to 13.5 times higher than plain HNSW at 90% recall, and in Weaviate 1.40 the strategy switches on an existing index without a rebuild.

Why this matters to a business

Take a car rental company with two years of booking history in its database. The owner's question: how many cars of which class will sit idle in November, and is it worth adding two more for the season. A model like Kumo Relational promises an answer from that same database per query, and the time series ensemble gives a range of demand by day, with an interval instead of one number.

The second question is of the "what happened back then" kind: a client argues that in March he was promised a different price. If the correspondence, call recordings and managers' notes sit in one database with timestamps and a link to the booking, a search by words and meaning with a filter by client and month finds the right phrase in seconds. The conclusion: the main condition here is history in the database, with time and links between tables. You don't need a new database for this.

How it works for me

In spring 2023, I built a financial dashboard from scratch for a consulting company in London. We pulled stock data from the Morningstar API, added news and passed it all to ChatGPT. For each company this produced a summary table with a tentative assessment of where the stock might go. It was not a guaranteed forecast or an investment recommendation. What that dashboard taught me: a model on top of data answers with a table, and a person decides.

At the PDR company in the US, the data has been in MariaDB on its own server since 2023: calls with AI analysis, leads, orders, 15 leaderboard metrics per employee. The question "what happens to the lead flow next month" can be asked of that database today. I haven't run Kumo Relational or the Granite ensemble; I'd test them on the lead history since 2023 against a forecast based on last year. If there's no gain, the model isn't needed.

What I would do

I'd start by checking the database: do events have timestamps, are the tables linked by keys, does history get overwritten when a record is updated. Without that, neither forecasting nor search works.

I'd pick one question the owner is willing to pay for and compute the answer the simplest way: last year plus growth. That's the bar the model has to beat. I'd store the forecast in the database next to the actuals, with the calculation date and the interval.

I'd do history search in the same database, with filters by client and time. I'd set up a separate vector store only when I hit a performance wall.

Agent memory, if it's ever needed, I'd start with a tree and filters, as in TigerData's third attempt, and I wouldn't give the agent free SQL.

Related reading

On verifying model output: AI in data processing: extraction and verification. The approach: Python for documents, data and repeatable processing and spreadsheet automation and business reporting. Cases: a financial dashboard in Google Sheets, a consulting company in London and a service team and conversion up 30%. From the digests on the same topic: three database decisions people regret later, AI decides, a person confirms and how I choose between my own model and an API. Earlier: hybrid search and tokenization and knowledge graph or vector RAG. If your company's history already sits in a database, tell me what the first question to it is. Discuss your task.