Architecture
What beVault is made of, and what stays with you.
This page describes the platform's technical architecture: the beVault components and their role, the people who use them, and the boundary with what belongs to you — data sources, infrastructure, target databases, outputs and deployment context.
Architecture diagram
beVault components and your environment
Users work in metaVault and States; Workers execute processing, read sources, and load your infrastructure's target database, which then feeds your outputs.
The starting point
An architect's first question
Before talking features, an architecture team wants to know what is installed, where it runs, what crosses the network, and what stays under its control. That's a question of architecture, not licensing.
beVault is deliberately kept lean: three components, separated responsibilities, and an explicit boundary with your application landscape. Everything else — your sources, your infrastructure, your target databases and your reporting tools — remains your domain.
Components
Three beVault components, used by your teams
The separation between modeling, workflow definition and execution lets the model evolve without rewriting the processes.
- 01
metaVault — the modelling environment
Your teams describe the model there: business entities, business keys, relationships, and attributes. The metadata entered here drives the generation of structures and loading code.
- 02
States — the workflow definition layer
This is where extraction and export workflows are described: which data is retrieved, in what order, under what conditions, and to which destinations.
- 03
Workers — execution
The execution components. They run the workflows defined in States, apply the generated code and perform the loads into the target database.
Your scope
What stays with you
The sources remain your systems: business applications and files present in your application landscape. Workers read the data there, drop it into staging, then apply the loads to the target database you've chosen.
Integration and connectivity- Target databases
- Snowflake, Amazon Redshift, Microsoft SQL Server and PostgreSQL are supported today. Databricks, Microsoft Fabric and Google BigQuery are coming soon.
- Outputs and consumption
- Prepared data is made available to the reporting tools and consuming systems in your environment.
- External orchestrator
- AWS Step Functions is supported as an external orchestrator. It is not a target database.
Deployment context
Where the platform runs
You decide where components are located; the boundary with your environment stays clear.
Components are installed in the environment you choose — on-premises, cloud, PaaS or hybrid — with Docker as the deployment technology.
Next step