No export and re-import
You are not moving a model out of a design tool and into a pipeline, or a schema out of a pipeline and back into a diagram. The thing you drew is the thing that executes, so the two cannot drift apart while nobody is looking.
Platform architecture
Three component types, and both hand-offs are files you can read
The platform is not one application with a database behind it. It is a small number of container types you compose, connected by outputs you can open and inspect. That is what makes it possible to run one component and not the others, to scale the part that is slow, and to know exactly what crossed between them.
The three component types
Studio authors it. Transformers run it. Writers land it.
Every deployment is some number of these three. A proof of concept might be one of each. A production setup might be one Studio, six Transformers across four source systems and two Writers pointed at two databases. The model does not change shape between those two.
Studio
Authors the model and the mapping files, validates them, publishes a version.
outputs · model + .map
publishes
v14
v14
Transformers
Execute the mappings against SQL, APIs, Kafka and files. Resolve identity, quarantine what does not fit.
outputs · resolved records
hands off
batches + cdc
batches + cdc
Writers
Emit your database's native load in insert or update mode, and keep it current through CDC.
outputs · your graph database
Modelling and ETL, together
The mapping and the model are the same artefact
Most stacks keep graph modelling in one tool and the ETL in another, and then spend their time keeping the two in agreement. Putting them in one place is the single decision the rest of this architecture follows from.
The mapping is traceable to the model
Every mapped field points at a class or property that exists in the published ontology. That is what lets a mapping be checked rather than reviewed, and what makes a question like “where does this property come from” answerable in one place.
gives a checkable link
Change is visible immediately
Adjust the model and the mappings that depend on it are right there. You can try a different transformation strategy and see what it does to the graph, rather than proposing it and waiting for someone else's sprint.
shortens the loop
The experts stay in the room
The people who know what a Supplier is do not have to hand the definition to the people who write the ingest. Modelling and mapping are the same screen, so the domain expertise and the plumbing stop being two teams and two queues.
removes a queue
Ontologies and vocabularies
Most of your model has already been agreed by somebody else
The parts of a domain that are genuinely yours are worth the argument. The parts that are not are worth borrowing, and borrowing them is what makes a graph legible to anyone outside the team that built it.
the vocabulary
Reuse the standard, extend where you differ
A model in Studio can pull in established vocabularies and sit your own classes alongside them, each in its own namespace. Names like a person, an organisation, an address or a date range have accepted definitions already, and using them means an outside tool, a partner or an assistant can read your graph without a glossary. Where your domain genuinely differs, and it will, you define that part yourself and it lives under your own namespace, clearly yours rather than quietly overloading something standard.
The consequence: the ontology reads as a description of your business rather than as a private code, and the argument about naming happens once, over the part that actually needed it.
namespaces
customer-v14
namespaces in use
gbo: yours, and the part you argue about
schema: schema.org
prov: W3C PROV-O
skos: concept schemes
owl: rdfs: the substrate underneath
published together as one ontology, versioned as one thing
Deployment
Every component is a container, and all of them are yours
There is no hosted tier holding your data and no control plane phoning home. The platform runs where you put it, which for most of the organisations we work with is the only version of this that gets past a security review.
running it
A laptop, a datacentre, or your own cloud account
Studio, the Transformers and the Writers are Docker containers, brought up together and configured with environment variables and mapping files. The same compose file that runs on an engineer's laptop runs on-premise or in your own AWS, Azure or Google Cloud account. Because the components share nothing, the one that is slow is the one you run more of, and the ones you do not need you simply do not deploy. Your database credentials and your source system credentials stay on your side throughout.
The consequence: the security conversation is about a container in your own account, not about which of your systems a vendor is allowed to reach.
your deployment
docker compose
your deployment one compose file
studio the IDE and its API
transformer one per source kind, scaled out
writer one per target database
kafka hand-offs, CDC, failure queue
studio node the MCP endpoint, if you want one
deploy the ones you need, and none of the ones you do not
bringing it up
bash
# the whole platform is one file
docker compose up -d
# the same file runs on a laptop, on-premise, or in your own cloud
# deploy the components you need and leave out the ones you do not
# nothing calls home, and no data leaves your account
Does any of our data reach you?
No. Every component runs in your infrastructure, and the hand-offs between them are files on your own storage and messages on your own Kafka. We see your data when you show it to us on a call, and not otherwise.
Can we run only part of it?
Yes, and plenty of setups do. Studio without Writers is a modelling and transformation tool that produces files. Transformers without Studio is possible too if you would rather author mappings by hand, since they are RML and R2RML. The components share nothing but the artefacts that pass between them.
What happens when one part is the bottleneck?
You run more of it. Transformers and Writers hold no state between runs, so throughput is a scaling decision rather than a re-architecture. A first load that is taking too long is usually four containers away from not taking too long.
What does Kafka do here, and is it required?
It carries hand-offs between components, the change data capture stream, and the failure queue that holds records which did not fit the model. For a batch setup reading files and writing to a database you can keep the topology simpler. For change data capture it is doing real work and is not optional.
Where does the agent-facing surface sit?
On your Studio Node, alongside everything else, and it takes a bearer token your instance issues. It exposes published ontologies to an MCP client and nothing else: it cannot run a Transformer and it cannot write to a database. There is more detail on the MCP page.
How do we get the model out if we leave?
The ontology is OWL, the mappings are RML and R2RML, the transformation output is RDF or node and edge CSV, and the model history is a git repository. All of those are open formats readable without us. We would rather you did not leave, but the exit should not be the reason you stay.
One tool for the whole of graph production
Bring an architecture diagram and the constraints you have been given. Most of the interesting questions on this page are easier to answer against a real environment than in the abstract.
- Runs in your account, on your infrastructure
- Docker on a laptop, on-premise, or in your cloud
- Open formats throughout, no lock-in to unpick