Deprecations and migrations
This page lists compatibility behavior and changes that affect existing applications and deployments. The command reference and examples describe the current API. The lists below distinguish compatibility syntax that still works from features that have been removed. GetApiSchema favors current spellings: it omits DiagnosticTool, deprecated result selectors, and legacy constraint syntax. Some compatibility fields, including GetStatus.cpu_utilization, remain in the schema. Schema presence alone does not establish that a field is recommended or fully implemented; use the command reference and migrations below.
Deprecated features
These features remain accepted for compatibility. Use the replacements in new code and when updating existing applications.
Deprecated feature | Replacement |
|---|---|
Property-keyed constraint objects, including object-form groups | Use Array expressions, including in connection filters and |
| Put these parameters at the command level. See sort, limit, group_by_source, and uniqueids. |
Comments in JSON requests | Send standard JSON without comments. Keep explanations outside the request payload. |
| Use |
Omitting | Specify |
Descriptor engines | Use |
| There is no general replacement command. Use the documented administration interfaces for your task; contact support for database repair procedures. |
| Select storage with |
| Use host or container CPU monitoring. This compatibility field always returns zero and does not measure CPU use. |
Descriptor engine names are case-sensitive. New or updated engine values are stored using the current names. Existing stored aliases remain readable without a manual metadata migration. Omitting an engine when creating a descriptor set still selects IVF; this default is supported.
Accepted options without effect
The following fields remain accepted but do not affect the response or server behavior. They can be removed from existing requests and configuration files.
Field | Behavior |
|---|---|
| Accepted configuration fields with no active collection behavior. |
| Accepted but does not enable periodic status logging. |
Finding deprecated usage
Use the deprecated_usage_total counter from GetMetrics to identify compatibility features used by your applications. The feature label identifies the feature. Counts accumulate until the server process restarts; reading metrics does not reset them. A request can increment more than one counter, including requests that later fail.
Feature label | What it counts |
|---|---|
| Property-keyed constraint objects, including conditional and nested filters and object-form groups. |
| Sorting specified inside |
| JSON parsed with comments. |
| Index commands using the old selector names. |
| Index creation or removal without an explicit |
| Resolutions of |
| Resolutions of |
| Resolutions of |
| Uses of |
These counters do not cover every feature listed above. Descriptor engine counters include command execution and reads of stored descriptor-set metadata, including background refreshes. They count alias resolutions, rather than unique requests or descriptor sets.
The Grafana Deprecations dashboard shows usage rates and cumulative counts for currently scraped processes. Cumulative counts include uses first observed at startup; rates cannot capture those uses without an earlier sample.
This metric family is included in the default JSON and Prometheus responses. To request only deprecation metrics:
[{
"GetMetrics": {
"metrics": [{"family": "deprecated_usage_total"}]
}
}]
Removed features and response changes
These forms are not part of the current API. Dated changes cover 0.19.13 onward, newest first, matching Release Notes. Entries without a version describe current requirements without assigning a removal release.
Previous feature or format | Migration |
|---|---|
Flat GetUsers and GetRoles responses (0.20.0) | Read named entries from |
Named remote credentials (0.20.0) | Identify credentials by |
| Remove these configuration fields; they are rejected. See Configuration File for current session settings. |
Authenticate or RefreshToken alongside other commands (0.20.0) | Submit each as a single-command query, then use the returned session token for subsequent queries. |
| Read an object containing |
| Read |
| Use |
Index type options | Use |
Index identifiers returned as | Identify an index by target, class, property, and kind. |
Numeric | Use |
| Use |
| Use |
| These configuration fields are rejected. Configure |
Helm | Select the chart version. Published charts pin the database and Web UI images together. |
OpenTofu | Select the module package tag. These inputs are not available; the |
| Use |
Tools image | Use |
Deployment recipes
Earlier setup pages included hand-maintained Docker Compose recipes, including start_files/docker-compose.yml and the notebook setup example. Those recipes are not the configuration for the published Compose packages.
Use the layouts and environment settings in Deploy with Docker Compose. The package contains coordinated service images and configuration. Transfer storage settings, credentials, published ports, and TLS settings through the package’s documented environment variables rather than copying an old service configuration unchanged.
Database upgrades
For a supported upgrade to 0.20.0, existing users, roles, personal tokens, and usable remote credentials are imported. Existing sessions and refresh tokens are not retained, so sign in again. Afterward, manage security settings through the API; editing the old access-control files no longer changes access. Review imported origins and test media reads as described in Remote credentials. See Access Control for current session rules.
Databases from 0.19.13 must complete the 0.19.14 upgrade before moving to 0.19.15 or later. Those later releases do not include the 0.19.14 conversion. Startup rejects incompatible databases; preserve their data and logs and contact support instead of deleting files to force an upgrade.
Upgrade procedure
-
Record the server version from GetStatus, client versions, deployment package tag, configuration, and storage locations. Read Release Notes and this page for every intermediate release in the upgrade path. Update applications that consume changed request or response formats before changing production.
-
Stop application writes and take a verified, restorable backup. Preserve database and object data, required coordination state, credentials, configuration, package references, and OpenTofu state when applicable. A chart rollback or an older image is not a database backup.
-
Rehearse the upgrade and representative reads and writes on an isolated restore. Preserve deployment identity and storage locations. Allow for service interruption; the deployment guides do not establish a zero-downtime or mixed-version upgrade guarantee.
-
After each required upgrade step, inspect logs and validate application queries and schema consumers. Connect and verify the deployment describes connection checks. Resume writes only after validation succeeds.
If validation fails, keep writes stopped and preserve logs. Restore the pre-upgrade backup with its matching software and configuration; downgrading binaries does not establish that storage conversions have been reversed.