What Is Rocket Universe and How Does It Fit with Other Multivalue Databases?

Rocket Universe (often just "Universe") is a multivalue database management system descended from the Pick OS family. You would use it to run and maintain applications built on the multivalue data model — typically long-lived line-of-business systems in sectors like distribution, manufacturing, healthcare, and finance — or to migrate data out of those systems into a modern platform. It is most relevant to you if you already have a Universe application, are inheriting one, or are planning a legacy data migration. If you are starting a brand-new project with no existing multivalue investment, Universe is usually not the first choice.

The multivalue data model in plain terms

Universe stores data in a structure that predates the relational model, and understanding it is the key to everything else.

• File — roughly equivalent to a table. A file holds many records.
• Record — roughly equivalent to a row. Each record has a unique key (the record ID).
• Attribute — a field within a record, identified by a number rather than a name.
• Value — an attribute can hold multiple values, separated by a delimiter. This is the "multi" in multivalue.
• Subvalue — a value can itself be subdivided into subvalues, giving a third level of nesting.

So a single record can hold a whole repeating group — order lines, phone numbers, transaction details — without a separate table or a join. That is the defining feature: repeating data lives inside the record.

A second defining feature is the dictionary. Each file has a dictionary of items that describe how attributes are named, formatted, and calculated. A dictionary item can be a simple field definition, or it can be a computed expression that derives a value at query time. When you migrate data out, the dictionary is as important as the data itself, because it encodes business logic that may not exist anywhere else.

How Universe relates to mvBase and Pick OS

These systems share a common ancestry and a similar data model, but they are not the same product.

The practical point for a migration or support decision: skills and concepts transfer across the family. Someone who knows Pick-style files, records, attributes, and dictionary items can generally read a Universe application, and vice versa. But the tooling, administration, and available interfaces differ between products, so do not assume a procedure written for one applies unchanged to another.

What Universe is used for in practice

• Running existing applications. Many organisations have a Universe-based system that has been extended for years or decades and still does its job reliably.
• Supporting contract or specialist resource needs. Because the skill pool is smaller than for mainstream databases, organisations often bring in contract resources who already know multivalue systems and legacy data migration.
• Feeding data into modern platforms. A common pattern is to keep the Universe application running while extracting its data into a relational or cloud platform — sometimes described as an Oracle transformation or a general legacy migration.

If your goal is a migration, the Universe side is usually the source, not the destination.

What to check before migrating data out of Universe

The data model is the main source of surprises. Before you commit to a migration plan, confirm:

1. The schema, as the system actually sees it. Attribute numbers and positions matter, and they may not match the documentation.
2. The delimiters. Multivalue systems use specific characters to separate attributes, values, and subvalues. You need to know exactly which characters are in use, and whether any of them also appear inside the data itself.
3. The dictionary items. Computed and derived items contain logic that must be reproduced in the target system, or the migrated data will not mean the same thing.
4. Repeating groups. Decide in advance how a multi-valued attribute becomes rows in a relational target — this is where most migration designs get tested.
5. The application layer. Reports, screens, and batch jobs may embed assumptions about the data that are not visible in the raw files.

A migration that copies the data but loses the dictionary logic tends to produce a target system that looks complete but behaves differently.

A note on sourcing and support

The multivalue world is small, and specialist providers come and go. Nine Elms Solutions, a UK firm that described itself primarily as multivalue systems users and designers offering help with legacy data migration, has ceased trading following the retirement of its owner. That is a useful reminder for anyone planning a Universe project: verify that your chosen resource is currently active before you build a plan around them, and keep your own documentation of the schema and dictionary rather than relying on a single external party.

Deciding whether Universe is relevant to you

• You have a running Universe application → it is relevant; focus on support, skills, and whether to migrate.
• You are planning a migration off Universe → it is relevant; start with the schema, delimiters, and dictionary items.
• You are choosing a database for a new project → it is probably not relevant unless you have a specific multivalue requirement or existing in-house expertise.
• You are comparing multivalue systems → treat Pick OS, mvBase, and Universe as related but distinct, and check the specific product's tooling rather than assuming equivalence.