Neo4j Aura (pay-as-you-go) is primarily used for research and production-grade graph analytics, including knowledge graph construction for complex relational data and graph-based reasoning and traversal for AI-driven analytics.

Neo4j Aura has been valuable in terms of reducing infrastructure management overhead, providing a managed, scalable Neo4j environment, and enabling faster iteration on graph-based research and applications. However, this value was significantly undermined by the recent incident where the service was suspended without prior notice, leading to several hours of data inaccessibility. For mission-critical workloads, service continuity and predictable lifecycle management are as important as technical performance.

Neo4j Aura (pay-as-you-go) could be significantly improved in the areas of service lifecycle management, communication, and migration handling, based on my recent experience. Specifically:

- Advance notification and transparency for service suspension: My Aura project was suspended without prior notice, immediately making the database inaccessible. For a managed database service, users should receive clear advance warnings before any suspension that affects data availability.

- Clear handling of AWS Marketplace legacy subscriptions: The transition from a legacy AWS Marketplace listing to a new listing was not communicated clearly. When I followed the instruction to 'update' or re-subscribe, a new organization and project were created automatically, while my existing project remained suspended with no visible option to re-link the active subscription. This created confusion and operational risk.

- Explicit migration guidance in the UI and subscription flow: It was not clear that migration to a new project was mandatory and irreversible. This information was only provided after contacting support. Such constraints should be clearly surfaced before a user takes action.

- Reasonable and safe migration windows: After requesting emergency assistance, the suspended project was temporarily unsuspended for only one hour to allow snapshot and migration. This timeframe is not sufficient for safe migration of a non-trivial graph database and exposes users to unnecessary data loss risk.

Key areas for improvement include service governance and communication, especially around subscription transitions and deprecations. There should be clearer visibility and warnings for legacy subscription lifecycle changes. Safer and more flexible migration windows are needed when forced migration is required. Users also need explicit UI guidance for re-linking subscriptions or understanding when re-linking is not possible. From a user perspective, process reliability is as critical as technical features.

I have used Neo4j Aura (pay-as-you-go) for 2 years.

The pay-as-you-go pricing model is generally reasonable and suitable for scalable workloads. However, users should be aware that pricing transparency alone is not sufficient. Subscription lifecycle changes, such as legacy marketplace transitions, can have a significant operational impact. Clear advance communication around such changes is essential to make pricing truly predictable.

Neo4j Aura is a technically strong and capable managed graph database, and it has been valuable for research and production use. However, this incident revealed a serious gap between technical capability and operational governance. A production database service was suspended without prior notice, and a platform-side marketplace transition effectively forced migration. The responsibility and risk of emergency migration were placed almost entirely on the user, and only a one-hour window was provided to safeguard existing data. I am not opposed to migration or platform evolution. What I strongly advise is that such changes be handled with clear advance communication, explicit explanations of irreversible actions, and migration timelines that are realistic and safe.