Verify an installation
Run these checks on a disposable database before accepting a new deployment or upgrade. Use the same binary, configuration, authentication mode, and storage filesystem planned for the application.
Check connectivity and execution
Start with readiness and the known-answer query. Then confirm that each application client selects the intended database and can authenticate with its own credentials.
Check writes and restart recovery
-
Load the small product dataset in Your first multimodal dataset. Record its key, vector index, entity IDs, and returned values.
-
Read the payload, search its named vector index, and query its
MADE_BYrelationship separately. -
Stop the server normally and wait for it to exit.
-
Reopen the same data directory with the same configuration.
-
Repeat all three reads and compare the identifiers and payload bytes with the saved values.
A combined query can hide which modality is missing. Separate reads make a failed recovery easier to diagnose.
Check application semantics
Run representative queries with saved expected results. Include empty results, missing properties, duplicates, and path limits if your application uses them. Verify result values and multiplicities before comparing latency.
If you use SpaceKey, also verify an identical batch retry, a conflicting retry, and an entity/time-window query after restart. The SpaceKey chapter describes batch identity and generation behavior.
Check access and resource settings
For multi-tenant deployments, test an allowed request and a denied request with non-administrator credentials. Confirm that query limits, timeouts, data-directory permissions, and listening addresses match your configuration.
Record the tested binary version, configuration, request bodies, expected results, actual results, and relevant errors. Remove credentials from shared logs. If a check fails, keep the old deployment available while investigating with health and query diagnostics.