Why We Had to Build a Spatial Engine from Scratch
CEO and Architect#
Q: You are the CEO of OZ. You are also the technical architect behind Arcflow. Those are not roles that usually sit in the same person. How do you think about that balance?
I do not experience it as two roles. The architecture of Arcflow came from years of collecting problem statements, not from sitting down one day and deciding to design a database.
When you run a company that processes spatial data at the physical edge, you accumulate a very specific understanding of what breaks. Every production incident, every performance bottleneck, every integration that should have worked but didn't. Those are problem statements. Over a few years, you have dozens of them. And when you lay them out together, the architecture emerges from the pattern of what is missing.
My job as CEO is to understand what we need to build and why. Arcflow was not a side project. It was the answer to a question the entire company was asking: why does no data layer exist that understands space the way our systems need it to?
Q: But you could have hired someone to build it. Why did you architect it yourself?
Because the problem statements did not come from database research. They came from fifteen years of working with spatial world data: 3D graphics, real-time rendering, game engines, GPU pipelines. The intuition about how spatial data should be organized in memory, how spatial queries should be evaluated, how GPU acceleration maps onto spatial workloads, that comes from decades in 3D, not from reading database papers.
In 3D graphics, space is the primary organizing principle. Scene graphs, spatial partitioning, frustum culling, level-of-detail: these are techniques that the 3D world solved thirty years ago because real-time rendering demands it. A game engine does not index spatial data as an afterthought. It organizes everything around spatial locality because the GPU demands it. The entire rendering pipeline is built on the assumption that nearby things should be processed together.
That intuition (space first, everything else derived) is what existing databases lack. And it is not something you learn from studying databases. You learn it from building 3D systems where spatial performance is the only performance that matters.
Starting from What Worked#
Q: Before you decided to build Arcflow, you used existing tools. What actually worked?
We ran Memgraph for a good while, and I want to be clear: it's a fantastic piece of engineering. A proper in-memory graph database with a team behind it that genuinely cares about performance and developer experience. I still recommend it to anyone building graph workloads that fit the traditional model. The people there are plain fantastic to work with.
Memgraph gave us the graph foundation we needed to prove that the Venue Graph concept was viable. Players as nodes, relationships between them, real-time updates in memory. For the core graph operations (traversals, pattern matching, relationship queries) it performed beautifully. We learned an enormous amount from running it in production.
Q: So what pushed you beyond it?
Two things that were not about Memgraph's quality, but about the nature of our workload.
The first was spatial. Our queries are fundamentally spatial: "who is near whom," "which entities will cross this boundary," "what is the closest camera to this event." These are geometry problems, not graph traversal problems. You can model spatial relationships as graph edges, and we did, but the graph does not understand that the edge represents physical proximity. It doesn't know that two nodes connected by a "within 5 meters" edge should be stored near each other in memory. The graph sees a relationship. We needed the engine to see space.
The second was our hardware architecture. Every OZ venue node has a multi-lane compute layout: a range of CPU cores for orchestration and control, plus multiple boards of powerful GPUs for inference and spatial processing. We were running graph queries on the CPU while the GPUs sat underutilised between inference cycles. The spatial workload (thousands of distance calculations, zone intersections, trajectory projections) is embarrassingly parallel. It belongs on the GPU. But no existing graph database could execute spatial predicates on GPU hardware.
We were leaving the most powerful compute on our devices idle for exactly the workload it was designed to handle. That was the problem statement that made the architecture obvious.
What Users Actually Need#
Q: You keep saying "problem statements." What do users actually need from a spatial data layer that they cannot get today?
Let me answer that from the user's perspective, not the engineer's.
A broadcast director needs to know which camera has the best angle on the ball carrier right now, not 50 milliseconds ago, right now. That means the system must know where every player is, where every camera is pointing, and which camera's field of view contains the action, updated every frame. If the data layer is even three frames behind, the director sees a camera switch to an empty patch of grass.
An analytics team wants to understand how a team's defensive shape evolved over a full match. They need to ask: "show me every moment when the back four's spacing exceeded 30 meters." That is a continuous spatial query over 90 minutes of position data, millions of spatial evaluations. The analyst expects the answer in seconds, not minutes.
A venue operator needs to know if a camera is drifting out of calibration. The system tracks whether the camera's reported field of view matches the spatial positions it should be seeing. If a camera says it is pointing at the penalty area but the entities it detects are consistently 2 meters off from where the other cameras place them, that is a spatial inconsistency the data layer should catch automatically.
These are not exotic requirements. They are everyday operations. But they all depend on the same thing: a data layer that understands physical space as a first-class concept, not as coordinates stuffed into a column.
Gudjon Gudjonsson
Founder and CEO
“The architecture did not come from database research. It came from fifteen years of building 3D systems where spatial performance is the only performance that matters.”
How Arcflow Actually Works: In Human Terms#
Q: Explain Arcflow's architecture the way you would explain it to someone who has never touched a database.
Imagine a football pitch as a living map. Twenty-two players, a ball, referees, all moving constantly. Every sixteenth of a second, the map updates. Everyone's position shifts. The relationships between people change: who is near whom, who is inside which zone, who is about to cross a line.
Now imagine you could ask that living map questions, and get answers instantly. "Who is the closest defender to the ball?" Instant answer. "Will any attacker enter the penalty area in the next two seconds at their current speed?" Instant answer. "Which camera has the clearest view of the player receiving the pass?" Instant answer.
That is what Arcflow does. It maintains the living map and answers spatial questions about it faster than the map changes.
The reason this is hard is that the map changes 60 times per second and the questions must be answered before the next change arrives. Traditional databases were built for a world that sits still between queries. Arcflow was built for a world that never stops moving.
Q: What makes it fast enough?
Three design choices, each borrowed from how 3D engines have solved similar problems for decades.
The first is spatial organisation. Arcflow stores entities by where they are in physical space, not by when they were inserted or what their ID is. Players who are close to each other on the pitch are close to each other in memory. When you ask "who is nearby?", the answer is already sitting next to the question in memory. The system doesn't need to search; it just looks at what is already there.
The second is GPU-native processing. The spatial calculations (thousands of distance checks, zone boundary tests, trajectory intersections) are exactly the kind of parallel work that GPUs excel at. On our venue hardware, we have powerful GPU boards that are already on-site for AI inference. Between inference cycles, Arcflow uses those same GPUs for spatial processing. What takes 12 milliseconds on a CPU takes under half a millisecond on the GPU. That is the difference between keeping up with live action and falling behind.
The third is the frame budget. Game engines operate under a hard rule: everything must finish within 16 milliseconds or the frame drops and the player notices. Arcflow applies the same discipline. Every query has a hard time ceiling. The architecture guarantees completion within that ceiling. This isn't "usually fast"; it's "always fast enough," which is a fundamentally different engineering constraint.
Q: So Arcflow is essentially a game engine's spatial runtime repurposed as a database?
That is closer to the truth than most database researchers would be comfortable with. The storage engine borrows more from scene graph architecture than from traditional database literature. The query evaluator borrows more from GPU compute than from SQL planners. The temporal model borrows more from animation systems than from time-series databases.
The 3D world solved the spatial data problem decades ago, just in a different context. Arcflow translates those solutions into a queryable, persistent, production-grade system that runs on the same multi-lane hardware we already deploy to every venue.
The Multi-Lane Advantage#
Q: You mentioned the hardware layout. How does Arcflow take advantage of having both CPUs and GPUs on the same device?
This is one of the most underappreciated aspects of the architecture. Most databases are designed to run on one type of processor. They either run on CPUs or, in a few research projects, on GPUs. Arcflow is designed from the start for multi-lane execution.
The CPU handles what CPUs are good at: transaction management, graph traversals, query planning, coordination. The GPU handles what GPUs are good at: spatial computations, proximity searches, trajectory projections, zone intersection tests. The two run simultaneously on the same data, with a shared memory model that eliminates the cost of copying data between them.
On a typical venue query ("given the current spatial state, which cameras should be reassigned?") the CPU traverses the graph to identify relevant entities and their relationships, while the GPU evaluates the spatial predicates across all candidates in parallel. The results converge in under a millisecond. Neither processor waits for the other.
This is only possible because we control the hardware. We know exactly which CPU and GPU configurations are deployed at every venue. Arcflow's query planner makes lane decisions based on the actual hardware profile, not a generic assumption. It knows how much GPU memory is available, what the inference pipeline is currently using, and how to schedule spatial work into the gaps.
Q: How did you balance building this with running the company?
The architecture phase was not the time-intensive part. Collecting problem statements over years, that happened while running the company. Understanding what broke, what was too slow, what was architecturally impossible with existing tools. That was the CEO's job. The architecture fell out of the problem statements.
The implementation, taking the prototype to production, that was the team. My role shifted from architect to product owner once the design constraints were clear. The team brought the PhD-level graph theory, the formal correctness guarantees, the production hardening. The architecture came from accumulated problems. The engine came from exceptional engineering.
Arcflow was not designed as a database that happens to support spatial queries. It was designed as a spatial engine that happens to be a database. That distinction (which axis is primary) determines every architectural decision: how data is stored, how queries are planned, how hardware is utilised, and how fast the system can answer the questions that matter to the people operating physical venues.
What This Means for People Using the System#
Q: Looking back, what does Arcflow change for the people who actually use OZ's products every day?
The short answer: things that used to be impossible are now instant.
A replay operator used to scrub through footage looking for a moment. Now they ask: "show me the exact frame where player 7 entered the box while the nearest defender was more than 3 meters away." Instant. The spatial data layer knew the answer before the operator finished the thought.
A production director used to rely on instinct and experience to anticipate camera switches. Now the system tells them: "based on current trajectories, the ball will arrive at player 11 in 1.4 seconds, and camera 3 has the optimal framing angle." The director confirms or overrides. The spatial intelligence is always there, always current, always faster than human reaction time.
A venue operator used to discover calibration drift when a broadcast looked wrong on air. Now the spatial layer detects the inconsistency in real time (the camera's reported view doesn't match the spatial reality) and flags it before the match starts.
None of these are features we added on top. They are natural consequences of having a data layer that truly understands space. When the engine knows where everything is, where everything is going, and how everything relates to everything else, in real time, every frame, the applications build themselves.
That is what years of problem statements and 3D intuition produced. Not a faster database. A data layer that finally thinks the way the physical world works.