{"slug": "aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql", "title": "Aito v2: a predictive database over linked data, with vectors, graphs and SQL", "summary": "Aito v2, a predictive database engine that combines structured facts, full text, vectors, and linked relationships in one store, entered public beta on August 11, 2026, according to CEO and founder Antti Rauhala. The engine provides calibrated probabilities and factor-tree explanations for predictions, recommendations, and relational queries, with v1 remaining the production default during the beta.", "body_md": "Antti Rauhala\n\nCEO and founder\n\nAugust 11, 2026 • 14 min read\n\n*I would rather you ran a query than took my word for anything in this post. So the numbers here are the ones our own benchmarks produce, the unflattering ones included, and every claim is a request you can send yourself.*\n\nAito v2 is a new engine for the predictive database, and it is in public beta today. It holds structured facts, full text, vectors, and linked relationships in one store, and it answers queries about the unknown the same way an ordinary database answers queries about the known: you ask for a category, an account, a next action, a ranking, and it returns the answer with a calibrated probability and the reasoning behind it.\n\nTwo honest framings up front, because they matter more than any feature.\n\nFirst, v2 runs **alongside** v1, not on top of it. For the whole beta, v1 remains the production default. v2 is the successor engine, stable enough to build against and to cite, and we would rather you kicked its tires now than waited for a version number.\n\nSecond, this is a beta for a technical audience. The bar we set for ourselves was simple: you should be able to query v2 in your browser, write your own data to it, read numbers we did not massage, and reference the v2 surface in your own design. Nothing on that list is gated behind a sales call.\n\nHere is the whole thing in one picture before the details.\n\nHere is the query the rest of the post rests on. Ask v2 to predict a product category, and ask it to show its work:\n\n```\nPOST /api/v2/_predict\n{\n  \"from\": \"products\",\n  \"where\": { \"name\": { \"$match\": \"milk\" } },\n  \"predict\": \"category\",\n  \"select\": [\"$p\", \"$value\", \"$why\"]\n}\n```\n\nYou get back a ranked list, each candidate carrying a calibrated probability:\n\n```\n[\n  { \"$p\": 0.738, \"$value\": \"104\", \"$why\": { /* the factor tree */ } },\n  { \"$p\": 0.140, \"$value\": \"109\", \"$why\": { /* ... */ } }\n]\n```\n\nTwo things in that response are the whole point of a predictive database.\n\nThe `$p`\n\nis **calibrated**, which is a specific and testable claim: among the cases where v2 says 0.85, close to 85% really are that value. That is what makes the number safe to threshold an action on. A score you cannot trust the level of is a number you cannot automate against.\n\nThe `$why`\n\nis the **factor tree**: the evidence that moved the probability, readable by a person who has to trust or override the decision. When v2 does not have the evidence, it does not paper over it. v2 fails loud, with a typed error, rather than returning a confident empty answer.\n\nThe query above is not a special prediction endpoint. In v2, `_predict`\n\n, `_recommend`\n\n, `_relate`\n\n, and `_match`\n\nare named entry points into one query engine, dispatching on what you ask for, and `_search`\n\nsits alongside them for full-text retrieval with boolean operators. The same store, the same data, answers the whole surface.\n\nRank options against an objective, not just a label:\n\n```\nPOST /api/v2/_recommend\n{\n  \"from\": \"impressions\",\n  \"where\": { \"context.user\": \"veronica\" },\n  \"recommend\": \"product\",\n  \"goal\": { \"purchase\": true },\n  \"select\": [\"$p\", \"$value\"]\n}\n```\n\nAsk what actually relates to an outcome, which is the move an anomaly check or an approval-routing rule needs:\n\n```\nPOST /api/v2/_relate\n{\n  \"from\": \"impressions\",\n  \"where\": { \"product.tags\": { \"$has\": \"vegetable\" } },\n  \"relate\": [\"purchase\"]\n}\n```\n\nNotice `context.user`\n\nand `product.tags`\n\nin those queries. Those are **links**, relational edges walked by dot notation, and they chain: you can follow one several hops out, from a record to its vendor to that vendor's own history, in the same query, with a `$refs`\n\noperator to read an edge back from the entity it points at. The relationships live in the same store as the facts, so a prediction leans on the whole neighborhood of a record, not just its own columns, without a separate graph database to keep in sync. `$refs`\n\nreads an edge backward, here every product a user has ever ordered, walked in reverse through the orders that link them:\n\n```\nPOST /api/v2/_query\n{\n  \"from\": \"users\",\n  \"select\": [\"name\", { \"products\": \"$refs.orders.buyer.product\" }]\n}\n```\n\nThat backward read is also the door to using the store as a graph you *predict* over, not just traverse. Model your data as entities and edges, one row per `subject → relation → target`\n\n, and the same engine does node classification and link prediction. Classify an entity from its neighborhood, here a segment for anyone who has engaged with something:\n\n```\nPOST /api/v2/_predict\n{\n  \"from\": \"entities\",\n  \"where\": { \"$refs.edges.subject\": { \"$exists\": { \"relation\": \"engaged_with\" } } },\n  \"predict\": \"segment\"\n}\n```\n\nOr predict a missing edge endpoint, here which target a tech-role subject is likely to use:\n\n```\nPOST /api/v2/_predict\n{\n  \"from\": \"edges\",\n  \"where\": { \"subject.role\": \"tech\", \"relation\": \"uses\" },\n  \"predict\": \"target\"\n}\n```\n\nBoth answers come back calibrated and explained, like every other prediction, and `basedOn`\n\nlets one generalize to entities it has never seen. The [graph docs](/docs/api/v2/graphs/) go deeper.\n\nAnd the thing you query does not have to be a raw collection. A **view** is a derived relation defined in the schema: a link-join that exposes a relationship as navigable dotted paths with no content copied, or a union-merge that stacks several collections into one, column by column and lazily. You name it in `from`\n\nand filter, predict, and recommend against it exactly as you would a collection.\n\n```\nPOST /api/v2/_predict\n{ \"from\": \"search_index\", \"predict\": \"category\", \"where\": { \"name\": { \"$match\": \"milk\" } } }\n```\n\nViews are lazy by default, nothing is copied, so they stay cheap to keep around. For a hot path you can persist a union view as a materialized snapshot, built once and rebuilt with `POST /api/v2/schema/{view}/_refresh`\n\nwhen its sources change. Either way it is the same relation operators under a name, so the whole calibrated surface runs over a shape you defined once.\n\nText and vectors live there too. v2 has a `Vector`\n\ncolumn type and retrieves with `$nearest`\n\n, scores rows with `$similarity`\n\n, and can fuse nearest-neighbor evidence into a prediction with `$semantic`\n\n. That last one is the point of vectors in a *predictive* database: the meaning of the text becomes evidence inside the calibrated answer, not a separate search you reconcile afterward.\n\n```\nPOST /api/v2/_predict\n{\n  \"from\": \"tickets\",\n  \"predict\": \"category\",\n  \"where\": { \"embedding\": { \"$semantic\": { \"near\": [0.1, 0.9, 0.2], \"k\": 20, \"weight\": 0.5 } } }\n}\n```\n\nPure nearest-neighbor retrieval is the same store from the other side, `$nearest`\n\nwith a `having`\n\non `$similarity`\n\n:\n\n```\nPOST /api/v2/_query\n{\n  \"from\": \"products\",\n  \"where\": { \"$nearest\": { \"near\": { \"embedding\": [0.12, -0.03, 0.88] },\n                           \"where\": { \"category\": \"shoes\" },\n                           \"having\": { \"$similarity\": { \"$gte\": 0.8 } }, \"limit\": 10 } },\n  \"select\": [\"id\", \"name\", \"$similarity\"]\n}\n```\n\nTwo honest limits worth stating plainly: the vector search is **exact, with no approximate index yet**, and v2 does not encode your text for you by default, so you bring your own vectors (with an optional server-side embedder you configure). Exact search is the right first move for correctness. The approximate index is on the list, not in the box.\n\nAnd for the people and tools that prefer SQL, v2 speaks the **Postgres wire protocol**, and it is more than a read path. Inference is called inline, so a prediction is just a column:\n\n```\nSELECT ProductName, predict(GLCode)\nFROM invoices WHERE ProductName = 'Cloud Services';\n```\n\n`predict(col)`\n\nreturns the argmax and `predictions(col)`\n\nthe ranked distribution, and `recommend()`\n\nand `relate()`\n\nare callable the same way. Around that you get a real, if deliberately minimal, surface: `SELECT`\n\nwith `WHERE`\n\n, `GROUP BY`\n\n, `HAVING`\n\n, aggregates, and an `INNER JOIN`\n\nalong a declared link, which is a thin projection over the link rather than a row-copying join. Writes and simple DDL go over the wire protocol: `INSERT`\n\n, `COPY`\n\n, `CREATE TABLE`\n\n, and basic `CREATE VIEW`\n\n. Point `psql`\n\n, a JDBC or ODBC client, or a connector like DuckDB or `postgres_fdw`\n\nat it. It is early access and not a full Postgres, a small `SELECT`\n\nsubset by design, no subqueries yet and a SQL view definition is a single source with an equality filter (no `JOIN`\n\nor `UNION`\n\ninside it), but by construction it parses to the same `_query`\n\ncalls as the JSON API, so the two interfaces return the same answers. The full surface is in the [SQL docs](/docs/api/sql/).\n\nReads are only half of it, and the write path is open in the beta, with no invite and no sales call in the way. That matters more than it sounds, because in a predictive database a write *is* the learning step. Insert a corrected row and the next prediction already reflects it, with no retraining job, no redeploy, and no drift schedule to babysit. This is the write-back loop that lets an application get sharper as it runs: in v2 it is one ordinary insert.\n\nSome of the v2 work is not a feature you call, it is engine work you feel as better answers and a smaller bill. Briefly, and without overselling what is still settling:\n\n`$p`\n\nstays honest on messy data instead of drifting overconfident.The measurable ones, memory and latency in particular, will get their figures from the same verified run as the benchmarks below, and I would rather show them then than quote a number I have to walk back.\n\nA release post is where companies quote their best benchmark and move on. The more useful thing is to show you the shape of the results, wins and losses together, because a system that only reports its wins is one you cannot calibrate your trust in. These move as we optimize; here is where they stand today.\n\nWhere v2 is clearly ahead:\n\n`acceptor`\n\nat `processor`\n\nlink, nearly doubled its accuracy and moved from behind v1 to ahead, on the back of a recent scoring update with better link priors.Where v2 is not ahead, and we are shipping it anyway:\n\n*(Figures come from our beta benchmark suite, single-seed and on small test sets, n≈200 for invoice routing with roughly ±7pp of noise, so treat them as directional rather than final. I would rather under-claim than quote a number I have to walk back, and we will refresh them as the engine is optimized and a dedicated-hardware run lands.)*\n\nThe fastest way to lose a technical reader is to make them discover the caveats themselves. So, plainly:\n\n`SELECT`\n\nsubset over the Postgres wire, not a full Postgres replacement.If you want the argument for why a database should answer the unknown at all, and how predictive applications are built on it, that is [The Predictive Application](/blog/the-predictive-application/). If you want to see the substrate under real agents, the live demos are at [agent.aito.ai](https://agent.aito.ai/). If you want to read the surface in full, the [v2 API docs](/docs/api/v2/) are open.\n\nAnd if you are building something on it, reads or writes, I would like to hear about it. The fastest line to me is plain email: [antti@aito.ai](mailto:antti@aito.ai). I am the founder, and I would like to know what you are trying to build.\n\nEpisto Oy\n\nPutouskuja 6 a 2\n\n01600 Vantaa\n\nFinland\n\nVAT ID FI34337429", "url": "https://wpnews.pro/news/aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql", "canonical_source": "https://aito.ai/blog/aito-v2-public-beta/", "published_at": "2026-08-25 11:49:21+00:00", "updated_at": "2026-08-25 12:16:08.744552+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "ai-products", "ai-infrastructure"], "entities": ["Aito", "Antti Rauhala"], "alternates": {"html": "https://wpnews.pro/news/aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql", "markdown": "https://wpnews.pro/news/aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql.md", "text": "https://wpnews.pro/news/aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql.txt", "jsonld": "https://wpnews.pro/news/aito-v2-a-predictive-database-over-linked-data-with-vectors-graphs-and-sql.jsonld"}}