Over the past few months, our team - led by Taylor Smith - has been hard at work preparing a new console to support our customers.

Our Customers: What to Expect

We always strive to maintain the highest level of customer service and expect to maintain it as we transition our customers to the new console. If you have any questions about the change, please hit us up via chat!

Will I be automatically moved to the new console?

No. We will reach out to each customer to ensure they know about the move date and have a chance to ask any questions about the move.

Will the console update impact my graph access or access to the existing console?

No. Your graph database will be accessible as normal. Also, you will still be able to access the existing console during the transition.

Will I have to upgrade my database version?

For users on Neo4j 3.1 and above, no. If you're on 3.1 or later, you can upgrade when you're ready. (spoiler: we'll have new versions of Neo4j Enterprise available)

What do I need to do?

Nothing really. Once you're moved over, you'll notice some differences in the UI and new features.

Just be on the lookout for the notice for the new console's avaialability. We'll be sending out notices regarding changes before, during and after.

New Features

The UI will get a refresh, but we're also adding in some new features!

Dedicated Clusters

Ready to move from a single instance to a dedicated Neo4j Enterprise cluster? We got you covered!

While we've always provided clusters upon request, you can fire up a new one without having to ask :)

Zero Impact, Self-Service Upgrades

Another new feature we're really excited about is the ability to upgrade your graph sizing. Increasing memory, storage, cpu will become a zero impact, diy operation.  It'll be initially offered as "click-to-scale" your instances, but eventually you'll have preference settings to auto-scale your instances! 

Fail Over Resolution

Everyone hates hitting memory limits, m'kay. With the new automatic failover for certain situations, like out of memory exceptions, you get better uptime and better service.

High Availability by Default

Yeah. HA by default. Even for single database deployments. If we lose regions/zones, databases can be replaced on the fly with no human input required.

Faster Support Resolution

Every resolution is simpler and faster because the running container can be entirely replaced if needed, without losing any data!

What's next

Here's a few of the things we've got on deck:

  • Live edits on database configs
  • Custom backup schedules, more backup/export options (export to csv, export to my S3 account, etc)
  • Custom alerts for potential outages, usage warnings
  • Setup for multiple environments (dev, test, prod), clusters, datasets (raw data not requiring database) to be replicated to any environment or database