Put the Agile record where storage is cheap and query is standard. Structured product data as columnar Parquet on S3, Azure Blob or OCI Object Storage, vault files tiered by access pattern, and the whole thing readable from the SQL engines your data team already runs.
An engineering archive has an unusual access profile. It is written once, read rarely, must be kept for a decade or more, and when it is read the question is specific. Object storage with columnar files fits that shape almost exactly.
Structured Agile data lands as Apache Parquet, partitioned along the axes people actually query: product line, item class, revision date, change effective date. Columnar compression typically shrinks the footprint by an order of magnitude against raw rows, and predicate push-down means a query for one part number does not read the whole archive.
Vault files sit alongside, tiered by how likely they are to be needed. Recent drawings and current specifications stay on warm storage where retrieval is immediate; deep history moves to cold or archive tiers where storage costs a fraction and retrieval takes minutes rather than milliseconds. The catalogue is identical across tiers, so users search one place.
Because the format is open, the archive is not hostage to a vendor. Any Parquet-aware SQL engine reads it directly, the schema registers in a standard catalogue, and if the organisation changes analytics platform in five years the archive does not need migrating again.
Storage economics without giving up the ability to answer a question.
Parquet typically compresses product and change history several times over against raw rows, which is most of the storage saving.
Amazon S3, Azure Blob Storage, OCI Object Storage or any S3-compatible target, inside your own tenancy and region.
Age-based movement to cold and archive tiers, with retrieval expectations set per tier rather than discovered during an audit.
Readable from the query engines your analytics team already uses, without a proprietary client.
Immutability enforced by the storage platform for the regulated window, not by a policy document.
The archive lives in the region you choose, which matters when the technical data is export-controlled.
Storage design first, because retention and residency are hard to change afterwards.
Cloud provider, region and tenancy agreed against data residency and export-control requirements before anything moves.
Partition keys chosen from the real access patterns, and tiering rules set by document age and retrieval expectation.
Product, structure, AML and change history written as Parquet with counts reconciled per object family.
Files transferred with checksums verified on arrival and placed on the right tier, with object associations preserved.
Schema registered, retention rules applied, access logging enabled and the reconciliation pack signed.
Storage layout is difficult to change once terabytes are in place, and the decisions are cheap to make well at the start. Partitioning, tiering and residency all fall into this category.
Six choices shape what the archive costs to hold and how quickly it answers a question. They are settled in week one of the archive workstream rather than negotiated later.
Three ways to hold retired PLM data, and what each one really costs.
Capacity bought up front for a dataset that only grows slowly, plus refresh cycles, plus the floor space and the DR copy.
Cheapest per terabyte and useless under time pressure. Media ages, readers disappear, and nobody tests the restore until it matters.
Paying production-grade storage and backup for files whose last read was years ago, on a platform you are trying to retire.
Because of the access profile. Archived product data is written once and read rarely, but when it is read the query is narrow: one part number, one change order, one date range. Columnar Parquet compresses heavily against raw rows and supports predicate push-down, so a targeted query reads a fraction of the archive rather than scanning it. It is also an open format, which means the archive stays readable if the organisation changes analytics platform later.
Amazon S3, Azure Blob Storage, Oracle Cloud Infrastructure Object Storage, or any S3-compatible target, inside your own tenancy and in the region you choose. Region matters more than usual for PLM, because engineering drawings and specifications are often export-controlled technical data, and residency has to be settled before anything is written rather than corrected afterwards.
They are tiered by age and likely access. Recent drawings and current specifications stay on warm storage for immediate retrieval; deep history moves to cold or archive tiers where storage is a fraction of the cost and retrieval takes minutes. The catalogue spans both, so a user searches once and the tier only affects how quickly the file arrives. Every file carries the checksum recorded when it left the Agile vault.
Yes, that is the point of using an open format. The archive is readable from standard Parquet-aware SQL engines, and the schema is registered in a data catalogue with business descriptions attached so someone can query it without having learned the Agile object model. That also lets archived product history join to other enterprise data for analysis, which is often a second benefit nobody planned for.
At the storage layer. Object-level retention locks hold the data immutable for the regulated window, which means it cannot be altered or deleted inside that period by a user or by a storage administrator. Read access is logged with identity and timestamp. That combination is what makes the archive usable as evidence rather than merely as a copy.
Far less than the environment it replaces, and the shape of the cost changes. Instead of licences, database and application servers, production storage, backup, DR and the specialist who maintains them, you pay storage by the terabyte with the deep history on cold tiers, plus query costs that scale with actual use. For an Agile instance that is only consulted occasionally, the running cost typically falls by an order of magnitude.
Tell us your preferred cloud, region, vault size and retention window. We will come back with a partition and tiering design and an indicative storage footprint.