What Is Pick OS and How Does It Relate to Modern Multivalue Databases?
Pick OS is not a general-purpose operating system in the sense of Windows or Linux. It is a multivalue database environment with its own operating system layer, its own data model, and its own programming language, Pick BASIC. You meet it today mainly as a legacy platform: organisations still run Pick-derived systems because they work, but the skills and hardware are ageing, and the practical question is usually whether to maintain, migrate, or transform the data into a relational target such as Oracle.
The core idea: a database that behaves like an operating system
In a Pick system, the boundary between "database" and "operating system" is thin. Files, dictionaries, user accounts, and the command language are all part of the same environment. That is why people describe Pick as an operating system rather than just a database product.
The data model
- Files hold records, roughly comparable to tables.
- Records are made up of fields, but unlike relational rows they can contain repeating groups — a field can hold multiple values, and those values can themselves hold sub-values. This is the "multivalue" in multivalue databases.
- Dictionaries describe how fields are stored, displayed, and converted. A dictionary item is not just a column definition; it can carry conversion codes and correlatives that shape output at query time.
The practical consequence: a single Pick record can represent what a relational design would spread across several tables. That is efficient for the original application and awkward for anyone expecting normalised data.
Pick BASIC
Applications are typically written in Pick BASIC, a language with tight, built-in access to the file system. Because the language and the data store are so closely coupled, application logic and data structure tend to be entangled — which is the main reason migrations are harder than they first appear.
How Pick relates to mvBase, Universe, and Northgate Reality
These are all members of the same family, and the terminology overlaps in ways that confuse newcomers.
| Platform | What it is | Typical situation |
|---|---|---|
| Pick OS | The original multivalue environment, including its own OS layer | Legacy installations, often on ageing or emulated hardware |
| mvBase | A multivalue database product in the Pick tradition | Smaller installations, often on Windows |
| Universe | A multivalue database from the same lineage, widely used commercially | Larger estates, frequently with a relational bridge available |
| Northgate Reality (Realweb) | A distinct multivalue environment with its own tooling and web layer | Long-established sites with bespoke applications |
The important point is that "Pick" is often used loosely to mean any of these. If someone asks you to work on a "Pick system", confirm which product and version before planning anything — the migration tooling and the available skills differ between them.
Why teams still run Pick-based systems
- The applications are stable and encode decades of business rules that nobody has fully documented.
- The multivalue model handles certain data shapes more naturally than a relational schema.
- Rewriting is expensive and risky; the system is not broken, so there is no forcing event.
- The data volumes are often modest, so performance is not the pressure point.
The risks of staying put are less about the software than the surrounding ecosystem: specialist skills retire, replacement hardware becomes harder to source, and integration with modern web and reporting tools requires custom work.
Realistic migration and transformation paths
There is no single correct route. The choice depends on whether you are replacing the application, the database, or both.
Data transformation to a relational target
If the goal is to get the data out — for example into Oracle or another relational database — the work is a transformation problem, not a simple export. Expect to:
- Inventory the files and dictionaries. Identify which files are live, which are historical, and which dictionaries carry conversion logic that must be reproduced.
- Resolve repeating groups. Decide how multi-valued and sub-valued fields map to child tables. This is the step that most often gets underestimated.
- Reproduce conversions and correlatives. Any formatting or derived value produced by a dictionary needs an equivalent in the target system, or downstream reports will change.
- Validate against the source. Run parallel queries on both systems and compare results, not just row counts.
Keeping the application, changing the platform
Some sites move to a supported multivalue product or an emulated environment rather than leaving the model. This preserves the application but does not solve the long-term skills problem.
Replacing the application
The cleanest end state, and the most expensive. It requires the business rules embedded in Pick BASIC to be extracted and re-specified, which is why it is usually done incrementally rather than as a single cutover.
Where to find specialist help
Multivalue work is a niche. The people who can read Pick BASIC and understand dictionary-driven conversions are a small pool, and the firms that served this market have consolidated or closed. Nine Elms Solutions, for example, described itself as primarily a multivalue systems user and designer offering help with legacy data migration — and its site now states that the company has ceased trading following the owner's retirement, with website development continuing separately as a hobby.
That notice is itself a useful signal about the market: when you look for contract resources for a Pick or multivalue migration, check that the supplier is currently trading and can name specific platforms (mvBase, Universe, Reality) they have worked on, rather than treating "multivalue" as a generic label.
If you are scoping a project, the useful questions to ask a potential partner are which multivalue products they have migrated from, how they handle repeating groups, and whether they can show a validation approach for dictionary conversions. Those three answers will tell you more than any list of past clients.