Most things in 3.4 are actually fully compatible to older releases. The new S2 geo indexes are an exception here. They are a completely new implementation and use a different storage format. However, index data will be automatically be converted into the new format when upgrading from older releases (e.g. 3.3) to 3.4.

To be on the safe side, it is a good idea to consult the list of incompatible changes/changed behavior before upgrading: https://github.com/arangodb/arangodb/blob/3.4/Documentation/...

That may seem like a huge list at first, but many items on it should actually be minorities.

Search is a new feature that could be used without limitations, in every edition. It’s really powerful if you combine a full-text search with a traversal or document join.

Our Kubernetes operator attaches persistent volume claims to each ArangoDB pod. The k8s infrastructure automatically fulfills these claims with actual persistent volumes on most cloud providers. This gives you network volumes of the desired size. If a pod needs to be redeployed, it can come back with its data, even if it is scheduled to a different pod. If you are on an on-premise k8s cluster or want to use fast locally attached SSDs, we have a separated ArangoStorageOperator, which can fulfill the persistent volume claims with local volumes. In this case, of course, a pod cannot be redeployed to a different machine. However, the ArangoDB cluster layer handles synchronous replication and automatic failover automatically. Therefore, the fundamental problem of running stateful services in a k8s environment is essentially solved.