Intelligence belongs where the data lives.
Modern AI systems keep separating intelligence from the data it needs.
Databases live in one place. Vector search in another. Models somewhere else. Agents run through orchestration layers, queues, APIs, and synchronization jobs.
SynapCores starts from a different assumption.
The database should be the agent runtime.
SynapCores brings relational data, vectors, graphs, machine learning, LLM inference, and durable agents into one self-hosted engine, accessible through one query language.
Traditional architecture
SynapCores
SynapCores
SQL + Vector + Graph + ML + LLM + Agents
Diagram: a traditional AI stack chains an application through an agent framework, a queue and workers, a model server, a vector database, a graph database, and a SQL database — seven separate systems in sequence. In the SynapCores architecture, the application talks to one system, SynapCores, which provides SQL, vector search, graph traversal, machine learning, LLM inference, and agents together.
AI infrastructure became too complicated.
Production AI increasingly requires teams to assemble and operate a collection of independent systems.
A relational database stores operational records. A vector database handles semantic search. A graph engine handles relationships. Model servers run inference. Agent frameworks coordinate actions. Queues and workers keep everything moving. Synchronization pipelines try to keep each system consistent.
Every additional layer creates another network boundary, another failure mode, another security surface, another operational dependency, and another place where an AI decision becomes harder to reproduce.
We believe the architecture is the problem.
SynapCores
Diagram: ten separate systems — application, agent framework, SQL database, vector database, graph database, model server, queue, workers, sync jobs, and observability — collapse into one box labeled SynapCores.
The database is the agent runtime.
SynapCores was designed around one architectural decision: intelligence and data should share the same execution environment.
Instead of sending records across services so another system can reason about them, SynapCores brings reasoning to the records.
SQL, vectors, graphs, models, and agents operate inside the engine.
Agents are database objects, not external application processes.
In SynapCores, an agent can be defined as a durable schema object. Its state, tools, execution context, permissions, and decision lineage belong to the data system rather than an external orchestration framework.
That changes the architecture from a collection of connected AI services into one data runtime.
CREATE AGENT is DDL — an agent is a schema object, not an external process.
CREATE AGENT ticket_triage
PERSONA 'aidb-assistant'
TASK 'Triage the new ticket: classify urgency, check the customer''s
account and past tickets with execute_query, write a one-line
recommendation.'
ON INSERT INTO support_tickets
WITH (max_iterations = 5, allow_writes = TRUE, timeout_seconds = 60);
-- The agent's run history is a query against the data system, not a
-- separate application log:
SELECT agent_name, started_at, status, output, verified
FROM _system_agent_runs ORDER BY started_at DESC LIMIT 5;What follows from that belief
01
The standard outlives the vendor.
SQLv2 is an open specification.
We believe infrastructure should remain portable, inspectable, and implementable independently from the company that created it.
Infrastructure you cannot leave is infrastructure you should think twice about entering.
02
If it cannot be reproduced, it did not happen.
AI output without reproducibility is difficult to trust and harder to audit.
SynapCores treats decision lineage, execution context, and reproducibility as part of the data architecture rather than an observability layer added later.
03
The data does not move.
Sovereignty is not an optional deployment configuration.
SynapCores is designed to run where the organization's data already lives.
Sensitive records should not need to leave your infrastructure for intelligence to operate on them.
04
One language, or it is not one system.
Connecting five engines does not create one engine.
SynapCores is built so relational queries, vectors, graph relationships, machine learning, and inference compose through one language and one execution environment.
05
Advanced capability should not require a specialist for every layer.
SQL teams already understand their data.
SynapCores gives those teams access to AI, vector, graph, and machine-learning capabilities without requiring an independent platform for every workload.
06
Show the work.
The specification is public. The SDKs are public. The packages are public. The recipes are public. Community Edition is available to run on your own infrastructure.
We would rather be evaluated than believed.
Built for teams current AI infrastructure leaves behind.
Your AI stack has become the product.
You started with an application.
Now your team operates model servers, vector databases, queues, workers, orchestration frameworks, synchronization pipelines, and multiple data stores.
SynapCores is designed for teams that want to collapse that topology.
Your data cannot leave.
Banks, insurers, healthcare organizations, government agencies, security teams, and regulated enterprises often face a harder problem than model quality.
They need to prove where data went, how a decision was produced, who had access, and whether the result can be reproduced.
SynapCores is designed to run inside their infrastructure.
Your team knows SQL, not ML infrastructure.
Data engineers, analysts, security teams, claims operations, compliance teams, and application developers already understand the information they work with.
They should not need a separate machine-learning platform organization before they can build useful AI systems.
SynapCores brings those capabilities into the database workflow.
Fewer moving parts.
Typical AI stack
SynapCores
SynapCores Engine
One binary. One engine. One language.
Diagram: a typical AI stack of ten separate components — SQL database, vector database, graph database, model server, agent framework, queue, worker pool, synchronization jobs, multiple APIs, and network round trips — compared against the single SynapCores engine, which contains SQL, vector, graph, ML, LLM inference, agents, transactions, security, and lineage.
The language is bigger than the product.
SynapCores is built around SQLv2, an open specification designed to extend SQL into modern AI workloads.
SQLv2 brings relational operations, vector search, graph traversal, model execution, and AI operations into a common grammar.
The specification is public because we do not believe the language that describes your data architecture should depend on one vendor.
-- Before SQLv2: 3 systems, ETL pipelines, 500 lines of Python
-- After SQLv2: 1 query, 1 engine
SELECT
customer_id,
PREDICT('churn_model', customer_features) AS churn_risk,
GENERATE_TEXT('Offer for', segment) AS personalized_offer
FROM customers
WHERE embedding <=> EMBED('high-value customer behavior') > 0.85
AND last_purchase < CURRENT_DATE - INTERVAL '30 days';The Founder
Luis B. Mata
Founder & CTO — Author of the SQLv2 Specification
Twenty years of building regulated technology led to one conclusion:
AI architecture breaks down when intelligence and data live in separate systems.
Luis B. Mata has spent more than two decades leading technology organizations across telecommunications, aerospace, healthcare, fintech, and AI.
Across those environments, the same pattern kept appearing: critical data lived in one system while the logic responsible for interpreting it lived somewhere else.
Every additional boundary made systems harder to operate, harder to audit, and harder to explain.
SynapCores is the result of deciding that the problem was architectural rather than incidental.
Where the evidence came from
Not a résumé — the pattern that led here.
Early career
Avionica
Engineering Lead · Aerospace
Shipped encrypted SaaS telemetry systems now deployed in Boeing aircraft worldwide.
What it taught us
Telemetry and the systems that interpreted it lived in separate services — every boundary between them was another place data could drift from what it was supposed to prove.
Early-to-mid career
XG Technology
Director of Engineering · Telecommunications
Designed reinforcement-learning algorithms for self-organizing wireless networks.
What it taught us
The decision logic ran outside the data plane it depended on — reproducing the network's behavior meant reconstructing state from multiple systems after the fact.
Mid career
Burnalong
CTO · Healthtech
Built recommendation engines, real-time analytics, and custom NLP models achieving 85% churn-prediction accuracy.
What it taught us
The model layer sat outside the data system, making reproducibility and auditing harder than they needed to be.
Most recent
Natural Health Sherpa
CTO · Healthtech / e-commerce
Guided a migration to cloud-native infrastructure and helped scale revenue from $28M to $50M through data-driven personalization.
What it taught us
Segmentation and personalization needed the data and the logic in the same place to move fast — every extra pipeline slowed the feedback loop.
20+
Years as a technology executive
70+
Engineers scaled from zero
15M+
Users served
99.999%
Reliability achieved on aerospace workloads
$10M
Annual infrastructure cost removed
$28M → $50M
Revenue growth supported
Don’t take our word for it.
SynapCores is designed to be evaluated directly.
Others have written about it
Advait Ranade, writing in Bits and Pieces
“The agent didn’t get simpler — the reasoning, the guardrails, the structured output are all the same. What changed is where it lives and what has to run to keep it alive.”
He moved a production CrewAI agent into the database. Read what happened
SDKs
Python, Node.js, PHP, Laravel, Go
We are not building another AI service.
We are building the data engine where AI applications live.
Relational data, vectors, graphs, models, inference, and agents should not need six independent systems to work together.
We believe intelligence belongs where the data lives.
Evaluate the belief yourself.
Install Community Edition, run the examples, inspect SQLv2, and decide whether the architecture makes sense for your workload.