TETRA may be the most innovative startup you’ve never heard of. TETRA started as an attempt to make graph workloads faster and more efficient. It became something far more ambitious: a matrix-based data engine built on Collapsive Architecture that brings data representation, storage and query execution together. 

Approaching TETRA as a graph database is a good way to get introduced to it. But TETRA is nothing short of a paradigm shift, and the impact goes well beyond graph.

By George Anadiotis

Yet another graph database?

Graph technology is special. It makes relationships between things explicit, revealing connections and context that conventional data models often leave hidden.

There is no shortage of graph technology these days. I know, because I’ve been working in the field for 20 years, and keeping track of it for the last 10 years. As AI moves from experimentation into real-world applications, organizations  are looking for ways to give LLMs context that is relevant, connected and grounded in their own knowledge.

At the same time, vibe coding has lowered the bar for creating software, and graph technology projects are proliferating. Some days it feels as though another one lands every time I open LinkedIn.

So when Kyle Mickey began posting about TETRA in March 2026, I initially filed it under “yet another graph database”. But the performance claims and, more importantly, the suggestion that the design was fundamentally different got my attention. I wanted to understand what was different, and whether the claims held up to scrutiny.

This is how this journey unfolded, where it goes next, and why rethinking infrastructure is a big deal whether you are into graph technology or not.

A disclosure before we go further: I am now a Strategic Advisor to TETRA. I came for the graph database and stayed for the vision. That affiliation is relevant context for readers, and it is also why I have tried to distinguish what is a part of the conversation, what TETRA has published, and what remains to be demonstrated in customer deployments.

Meet the inventor: from English and geophysics to LLM kernels

Mickey, as he prefers to be called, studied English, psychology and the humanities, traveled with the idea of teaching English, then worked in health and human services before moving into technical writing and geophysics. 

From there came software configuration, engineering, application development and operations, including more than a decade on AWS. He now builds from Costa Rica. It is not the usual database founder’s résumé, which may explain why he asks unusual questions.

The path to TETRA began with a practical problem: making LLM inference more efficient. Mickey was working on GPU kernels and thinking about how an LLM could become just another capability in an API stack, rather than a separate architectural universe. 

As he read research on embeddings and the mathematics behind them, he kept encountering graph Laplacians and linear algebra. Work by Lorenzo Moriondo was one of the prompts that made him look more closely. One question stayed with him:

“Why would it be that embeddings are showing these same properties as a matrix, as a graph representation?”

Embeddings turn prompts into numerical representations that models can process. Mickey began to wonder whether the mathematical properties he saw in embeddings and model weights could also represent and query ordinary data. 

If graphs can be represented as matrices, could a database use that representation too?

Mickey profiled existing databases and traced where they slowed down: the system would fetch information from memory or disk, then return to processing. He started hacking away trying to answer one question: 

What if the system could stay in one numerical representation for more of the operation?

The prototype went by “Edge Glider” for months. The name TETRA came from an anonymous online chat: Mickey asked what to call it, and the answer was simply “Tetra.” It is the Greek word for four, and the tetrahedron is the simplest complex graph.

Collapsive Architecture: from LLM mathematics to a matrix database

The distinction between an LLM and a database matters. LLMs use trained, probabilistic representations. TETRAbase uses exact numerical operations: it tokenizes a query, maps it to algebraic operations, and applies sparse and dense matrix operations and vector mathematics to stored data. The goal is not a plausible answer, but the exact result of a database query.

Mickey calls TETRAbase a matrix database. Every database needs a query language. So, how do you query a matrix database? 

TETRAbase began by supporting openCypher, the graph query language associated with Neo4j, and later added SQL. Neo4j is the established reference point in the graph database market, making it a natural choice for both query language compatibility and performance comparisons.

Adding support for SQL was partly pragmatic: some organisations are more comfortable approaching their data through SQL than through a graph interface. But there is a deeper architectural point. 

If the data itself is represented in a matrix, the query language is an interface to that representation. As Mickey put it: “If the matrix is the data, I can wire up any query language against this matrix.”

That is different from translating graph queries into joins over a relational database. In TETRAbase, SQL and graph queries operate on the same matrix representation. 

TETRA calls the design Collapsive Architecture: structure, storage and execution are brought together in one linear-algebra space rather than maintained as separate layers.

Linear algebra in graph engines is not new. FalkorDB, for example, documents the use of sparse adjacency matrices and matrix operations. The distinction Mickey draws is that TETRA carries the matrix approach through the data model and storage layer as well as query execution, storing the matrix in tiles on disk and assembling what each query needs.

In his origin story, Mickey describes the Data Matrix as recursive: relationships between entities can themselves be represented as matrices, keeping entities and their connections within the same underlying structure.

What happens when a query runs?

TETRAbase does not keep the entire data set in RAM. Rather than keeping the entire database in RAM, TETRAbase loads only the portions of data needed to answer a query into working memory, releasing that memory as the query progresses. The footprint falls instead of remaining tied up holding the full graph.

The execution uses multicore CPU calculations; it does not require GPUs in the database layer. Mickey describes the contrast between continuous mathematical operations and the repeated pauses involved in fetching data and resuming the calculation vividly: 

“The query goes through the processor like a wood chipper.”

The practical proposition is faster query execution, less memory held per query, a smaller storage footprint and fewer tuning parameters. TETRAbase runs with no indexes or cache and is encrypted on disk.

“TETRA’s all math, so there’s really no index”, as Mickey puts it.

According to TETRA’s benchmark report, TETRAbase is 66x faster than Neo4j and handles 10.3x more queries per second, while using 2.1x less memory, 13x less CPU and 7.9x less disk space and being encrypted on disk. The report presents the measurements, methodology and cases where the comparison is less favourable.

These are company-published results, not an independently audited certification. The point here is the architecture that enables a combination of fast results and lean operation, not a leaderboard against any one vendor.

Why efficiency matters beyond the database team

But how does the architecture translate into business terms? Mickey’s answer was concrete: fewer machines, less operational effort and the potential to run workloads that once required a cluster on a single server. 

Moving from three database servers to one is visible on a cloud bill. TETRAbase does not need indexes or caches; fewer tuning surfaces also mean fewer operational tasks, and risks.

TETRA is designed to run in the customer’s own cloud, close to the systems that use the data. Offering TETRAbase via a SaaS model is possible, but Mickey argues that an external SaaS call would add network latency and dilute performance gains. He described the licensing model as based on instance and graph size, rather than per-query charges.

There is a bigger context for this focus on efficiency. Data centres’ electricity demand, water use, land requirements and effects on local power prices have become public issues. In U.S. local elections on November 3, voters backed restrictions or rejected data-centre development proposals. The social licence for the AI infrastructure buildout cannot be taken for granted.

This is where TETRA’s status as a Public Benefit Corporation matters. The company’s stated mission includes building technology that uses fewer resources, emits less carbon and expands access to useful tools. 

Mickey says TETRA’s internal modelling points to the possibility of reducing electricity consumption by more than 40% across the infrastructure used to store and query data. He is clear that this is a projection based on the company’s modelling, not a measured deployment result. 

It will only be possible to validate this at scale, and it should not be read as a claim about the energy used by GPU compute for training or inference. That distinction matters.

Efficiency claims are easy to make and harder to prove across real workloads. But as AI systems multiply, the answer cannot always be to add more infrastructure. Better software and more efficient use of existing hardware belong in the conversation too.

From TETRAbase to TETRAplex: simplicity as a prerequisite

For Mickey, the database is the first application of a more general idea. He invokes a line attributed to computer scientist Edsger Dijkstra: “Simplicity is prerequisite for reliability.” It is a succinct way to frame the ambition. 

Much of today’s software architecture is assembled from specialised services, APIs, databases, orchestration layers, security controls and observability tools. Each may solve a legitimate problem. Together, they can create systems that are difficult to understand, operate and trust.

Mickey is careful about where technology can and cannot simplify things. Data has an irreducible dimension involving semantics, ontology and meaning: where information came from, what it represents and whether it should be trusted. 

A faster database cannot answer those questions. But once data enters a system, he argues, there is scope to simplify how it is stored, processed, moved and acted upon.

That is the ambition behind TETRAplex, the next step on the roadmap. 

Mickey describes this as a way to assemble business workflows, connect them to LLMs and control the context each step receives. Failures should be handled explicitly and every change should have an identifiable actor. The aim is to make workflows reliable and observable before adding more autonomy.

Mickey made a point that is relevant to the current agentic AI conversation: “You can’t really have agentic workflows until you have reliable workflows.” 

In his view, an API flow and an agentic workflow are not fundamentally separate species; the difference is the level of autonomy. That is why he sees data, APIs and AI as parts of one architecture, rather than components that should be bolted together as separate systems..

Where TETRA stands, and what comes next

Today, TETRAbase is running on beta servers for initial design partners, prospective customers, as well as powering TETRA’s own applications. The core infrastructure has been stable for several months, with ongoing work to test edge cases and improve correctness. 

One check is to run the same data and query through TETRAbase and Neo4j, using the established graph database as a correctness reference. The story is not that existing graph databases are invalid; TETRA is exploring a different way to build.

TETRA has also been working with independent collaborator HorneSci on the mathematical foundations and code correctness. That is distinct from the performance benchmark, which remains TETRA’s own report.

The immediate next step is to onboard more design partners, understand their problems and deploy TETRA where it can make a measurable difference. 

The team will be at Connected Data London on November 11–12. For graph users, data architects and technology leaders, it is a chance to ask where a different data model might simplify existing workloads.

I started this journey  expecting to learn about another graph database. I came away thinking about a broader question: whether the way we represent, store and execute data is ready for a rethink. 

TETRAbase is the first test of that proposition; TETRAplex is the larger ambition. Neither should be taken on faith. Both deserve to be examined through architecture, evidence and real deployments.