OrientDB

Some applications need to store flexible records and also ask how those records connect, such as relationships between accounts, transactions or assets. OrientDB combines document storage with a graph model, where relationships are directly represented and traversed. It can fit applications whose questions span both individual records and their connections. Before deploying it on Kubernetes, establish the server and driver versions your application needs; database replication, durable storage and recovery require more than increasing a pod replica count.

Current guidance

Its versioned 3.2 manual remains available and describes SQL, drivers, transactions, distributed operation and backup. That establishes a useful documentation source; it does not establish the support entitlement or update policy for an arbitrary old image or Helm chart.

Before selecting a Kubernetes package, identify the actual server version, client drivers and data model your application uses. Check the matching version’s upgrade instructions rather than treating a container tag change as a transparent migration. Persistent storage, stable node identity and database-specific cluster configuration need separate attention from the Kubernetes replica count.

Read the distributed-architecture and backup sections together when designing recovery. A database cluster’s replication is not a substitute for a restorable backup, and a restore procedure that works on one node may require coordinated treatment of the other nodes. Rehearse the documented procedure using disposable copies, then verify representative graph traversals, document queries and application transactions. Protect database and administrative endpoints and keep credentials out of chart values committed to source control. Current chart maintenance and a production recovery path have not been certified by this review.