ForgeVault¶
ForgeVault is a portable, governed metadata and time-series store that can live wherever you need it — on-premises, in the cloud, or embedded.
It is a lightweight, managed alternative to a traditional historian, and it is particularly useful as an intermediary layer: a place to normalize, aggregate, and govern data on its way between a source system and the tools that consume it.
Status: available through an EEI engagement — real, in use, and supported today. What is planned is the self-service managed offering: the ability to provision and operate a ForgeVault instance yourself.
What it is for¶
Four situations where it earns its place. The first three are a store in the middle; the fourth is ForgeVault as the historian itself.
- Normalization before analysis. Source systems disagree about units, naming, and structure. Reconciling that repeatedly in every consuming tool is waste; doing it once on the way through is not.
- Aggregation. Raw resolution is rarely what an analysis needs. Pre-computed aggregates are cheaper to serve and faster to work with.
- A governed metadata home. When asset hierarchy has to be assembled from several systems — an ERP, a maintenance system, a spreadsheet somebody maintains — it needs somewhere authoritative to live before it can drive anything downstream.
- A general historian, when you would rather not run one. Sometimes the requirement is not a layer in the middle at all — it is the time-series store itself. A site needs one and has none; or has one that costs more than it returns; or needs a capability the incumbent does not have; or simply cannot get the incumbent to talk to what it needs to talk to. We can provision a ForgeVault instance to be that historian, with full time-series capability, and operate it for you. Some customers choose this because they would rather the relationship sit with us than with another vendor — a legitimate reason, and one we are glad to be picked for.
It is also the metadata source behind our metadata connector work: hierarchy is curated in ForgeVault, and the connector reflects it into Seeq without duplicating the underlying signals.
How content gets in¶
A store in the middle is only useful if there is a way into it, so: content arrives through an ingestion path built for the source. The source hands over the extract it already produces — no new interface to build on your side — and a procedure inside ForgeVault lands it as data and metadata tables. From there the data and the hierarchy are served into Seeq separately, which is what lets the asset tree reference your signals rather than copy them.
| Status | |
|---|---|
| SAP Quality Management — SAP QM's own CSV extract, landed as data and metadata | Available through an EEI engagement. Built for and proven in a production deployment |
| Another system — an ERP, a maintenance system, a historian export, a metadata database someone maintains by hand | The ingestion capability is available; each new source is specified and built as engagement scope |
Two things worth drawing out, because they are the reason this shape works:
- The source keeps its own format. We meet the extract where it is rather than asking a system of record to learn a new one. SAP integrations in particular are specific by nature, and a defined path per source is more honest — and more reliable — than a generic adapter that claims to handle everything.
- Ingestion happens at the database, not in Seeq. Adding a source changes nothing running inside your Seeq environment. That is what makes a second or third source an increment rather than a project.
Planned: today an ingestion path is set up as part of an engagement. The direction is for VirtualForge to become the managed way in, offering the same paths through the platform rather than configuring them per deployment. Committed direction — not something you can use today.
What it is built on¶
PostgreSQL with TimescaleDB — a deliberately unexciting choice. Both are mature, widely understood, and portable, which is what makes "wherever you need it" credible rather than aspirational. There is no proprietary storage format holding your data hostage.
Customer data is isolated at the database level: each customer gets a dedicated database with its own schema, rather than a shared table with a filter on it.
Who operates it¶
Three configurations. The honest answer is that we are flexible here, because which one is right depends on your constraints rather than on our preference:
| Configuration | Status |
|---|---|
| EEI-operated, using our own tooling and people | Available — what every current deployment uses |
| Operated through a specialist managed-service provider, whose entire business is running this class of database at scale | Planned — actively being worked on, not yet in place |
| Self-hosted on your own infrastructure, where residency or policy requires it | Available — portability is the point, so this is a supported shape rather than an exception |
On the middle one: a provider that does nothing but operate time-series databases brings economics and operational depth that a company our size cannot credibly claim alone, which is why we are pursuing it. The arrangement is not executed yet, so we are not naming a partner until it is — announcing someone else's involvement before they have agreed to it is not how we would want it done to us.
If that route does not suit you, or is not in place when you need it, the EEI-operated path does not go away. It is not a stopgap waiting to be replaced; it is one of the options, and it is the one in use today. Whichever configuration fits, the store and its behavior are identical — which is exactly what building on standard PostgreSQL buys.
Portability, and why it matters¶
"Portable" is the load-bearing word. The same store can run on-premises where data residency requires it, in the cloud where convenience wins, or embedded inside a solution where it is an implementation detail you never think about.
That flexibility exists because of a principle we take seriously elsewhere too: you should not have to relocate your data to get value from it. If the store can move to the data, the data does not have to move to the store.
Related¶
- Metadata Connector — what reads the hierarchy out of ForgeVault and builds it in Seeq. Seeq's own SQL connector will serve data out of a database but cannot build an asset tree; that is the gap ours fills.
- Connected Intelligence — why we reference data rather than copy it, and where a store in the middle fits that.
- Products — everything else in the portfolio, and where each stands.
- VirtualForge — the platform ForgeVault is part of.