Update December 16th, 14:13 UTC

As expected, Neo4j has released new 4.2 and 4.3 versions (4.2.13 and 4.3.9) that contain the latest Log4j (2.16.0) with the fix for the latest discovered attack vector CVE-2021-45046.

We have made both versions available for our customers to upgrade on our admin interface and we’re reaching out to affected databases with further details. For new databases, we have disabled all versions but 4.2.13 and 4.3.9.

–

Update December 15th, 14:00 UTC

It looks like an additional attack vector was identified and reported in CVE-2021-45046. Neo4j patch releases contain Log4j 2.15.0 which is still impacted. There might be new Neo4j patch releases shortly, so please stay tuned.

–

Original post

Security is a top priority at GrapheneDB and our Ops team has been looking into this exploit from the moment it went public. We’d like to share with you some known details and actions that we took to mitigate it.

On Friday (December 10th, 2021), we and many others became aware of a critical severity zero-day exploit known as “Log4Shell” in the Log4j library, which is widely used in numerous systems around the internet. It has now been published as CVE-2021-44228.

Our Ops team has been actively taking steps to mitigate and monitor the situation. Good news is that we didn’t find any breaches in the GrapheneDB system and databases.Services and components that use affected library are running newer java version which in combination with other applied security measures makes this vulnerability hard to exploit.

We want to use this opportunity to remind you that we have a feature to restrict access to your databases via IP Whitelisting or VPC peering.

With utmost security in mind, we don’t want to risk vectors that we might have overseen or are not discovered yet. That’s why we have taken the following decisions:

• We are following the official recommendations on how to mitigate the problem.

• Neo4j has released new 4.2 and 4.3 patch versions with a newer version of Log4j, which is not impacted. For new deployments we’ve removed the option to use affected versions and for existing databases we have a plan to upgrade them to new patch versions. If you have any questions or concerns related to this matter, please don’t hesitate to contact us by submitting a new support ticket or via email at support@graphenedb.com.

We’re happy to announce that we’ve improved visibility on how data is distributed in disk so that you can have more control over your deployment.

The size that your deployment takes in the disk is important as there is a limit for your plan that you want to avoid hitting (read-only mode). Also having a good visibility on your dataset size will help you to for instance how much of your dataset fits into page cache and avoid hitting disk for reads, which is slower.

As of today there is a new section in the Overview page of your database showing the following info:

• Databases: The size that your system db and your data databases takes in the disk. It also contains transaction files.
• Nodes, Properties & Relationships: The size in disk for your property graph model will help you understand how the data is distributed within your graph
• Indexes: Indexes are very important, but they come at a cost of write performance and disk size.
• Extensions: This is the size in disk of your extensions.
• Other: Other size in disk, like debug logs.

Prometheus endpoint All these storage metrics are also available via the Prometheus endpoint (see Insights tab) for your convenience in case you want to fetch them and create your own charts or alerts.

Email notifications We are sending now 2 warning emails at 85% and 95% before your deployment reaches the allowed disk size for your plan. We encourage you to upgrade your plan (you can do it now in-place) to avoid your database being put in read-only mode.

Moving forward We’re going to keep working in the next months on improving the visibility in the server. Please stay tuned!

We are proud to announce support for the following regions recently launched by AWS:

• South America (São Paulo)
• EU (Milan)
• EU (Stockholm)
• Asia Pacific (Hong Kong)
• Asia Middle East (Bahrain)
• Africa (Cape Town)

Customers in these regions can now serve their end-users better through low network latencies and are able to deploy their databases securely in any of the new regions.

All our new plans (single and dedicated) are available for deployment in these new regions.

Here is the updated list of regions GrapheneDB supports, by continents:

America

• Canada (Central)
• US East (Northern Virginia) Region (us-east-1)
• US East (Ohio) Region (us-east-2)
• US West (N. California) Region (us-west-1)
• US West (Oregon) Region (us-west-2)
• South America (São Paulo) - NEW

Europe

• EU (Ireland)
• EU (Frankfurt)
• EU (London)
• EU (Milan) - NEW
• EU (Stockholm) - NEW

Asia

• Asia Pacific (Tokyo)
• Asia Pacific (Seoul)
• Asia Pacific (Mumbai)
• Asia Pacific (Singapore)
• Asia Pacific (Hong Kong) - NEW
• Asia Middle East (Bahrain) - NEW

Oceania

• Asia Pacific (Sydney)

Africa

• Africa (Cape Town) - NEW

We are excited to grow our list of supported regions and serve our world-wide customer base better. If you have any questions, please feel free to reach out to us.

We’re delighted to let you know that we’re releasing new plans as of today. The highlights:

• More deployment options.
  We have been deploying clusters for our customers for years. Now, as part of this release we’re offering clusters also as self-service plans with 2 options: Neo4j Enterprise (BYOL) and also OnGDB.

• All plans dedicated.
  All new plans are going to be deployed on dedicated servers, from our smallest single plan to clusters.

• Neo4j 4 support.
  It’s been some time that Neo4j 4 is available and we have been adapting our services to support it. Now it’s ready with the latest 4.1 version.

• More CPU and RAM for the same price.
  We have adjusted our business margins to offer you better pricing. Most of the new plans offer twice as much RAM and CPU as the equivalent old plans.

• In-place upgrade/downgrade within all available plans. You will be able to change from any plan to any plan within our offering in place. Also between single and cluster plans. Everything in place and with no downtime between cluster plans.

• Inbuilt extensions.
  APOC and GDS have grown to be very popular extensions. That’s the reason we have included them pre-installed and ready to be enabled, just one click away.

How to migrate current deployments to new plans

We’re going to migrate all current deployments to its equivalent plan at some point in the next few weeks. In the meantime your current deployments running old plans will work as usual.

The migration will take place as a maintenance operation, which you will be able to opt in at your convenience. If you’re eager to migrate and don’t want to wait, please reach out to us via a support ticket and we’ll put you on a prio list.

Why are we dropping Hobby plans

When we started seven years ago, there was no option to quickly deploy Neo4j in the cloud. We came up with sponsoring Hobby plans to let new users evaluate Neo4j together with our offering.

Now there are plenty of options out there to very easily deploy a database in the cloud, making our Hobby plans not so relevant for new users.

Apart from that, Hobby plans are deployed on a massively shared infrastructure. Even though our Hobby plans were never meant to be used for production, our users have been dealing with expectations that we cannot meet for free plans.

That’s why we’ve decided to drop support for Hobby plans, focusing on dedicated servers in the future and providing the best possible solution as a graph database provider. Not having to maintain Hobby plans will free up resources that we’ll dedicate to implementing great new features for dedicated servers.

Old Hobby plans will still be working as usual and we’ll come up with a migration date and upgrade path to new plans in the coming weeks.

Nonetheless we still want to offer a way to evaluate our service, that’s why we are introducing trial databases, which will allow new users to test all our features with a dedicated database for 2 weeks for free.

Moving forward

If you have feedback or questions on our new plans, please contact us by submitting a new support ticket or via email at support@graphenedb.com.

We’re eager to share with you all the new features that are coming up this year. We’ll update you soon, so please stay tuned.

Here at GDB we are always trying to make things easier for our customers. With the release of Web socket and Bolt v3 support, connecting to your databases has become even easier!

Using the Neo4j Desktop client you can easily add a new graph and connect to your remote GDB database in the cloud. Please follow the how-to guide here to see just how easy it is to get connected!

Today we’re excited to announce that we’ve rolled out support for in-place plan upgrades and downgrades within our Performance tier.

So far, to upgrade or downgrade your plan at GrapheneDB you have been using our cloning feature. That means a new database is created out of a copy of your original database. This is a very safe method, as you can always switch back to the origin database if anything goes wrong, like for instance if there is a compatibility problem upgrading your Neo4j version.

As of today, if you just want to upgrade or downgrade your Performance plan you will be able to do it in-place. There is no need to point your application to a new database, neither to upload your extensions again. Plus, doing the upgrade operation in-place allows us to skip some steps compared to doing it via cloning, thus reducing the time your database needs to be down during the operation.

You can read more details about our brand new in-place plan upgrades and downgrades on our documentation.

We’re happy to provide more options to allow you to manage your deployments at GrapheneDB and we’re commited to keep delivering the best value and features for our customers. If you have feedback or questions please contact us by submitting a new support ticket or via email at support@graphenedb.com.

Stay tuned for more exciting announcements soon!

We’re happy to announce that we’re ready for new General Data Protection Regulation (GDPR) law, which goes into effect on May 25, 2018.

GrapheneDB has always been committed to the data privacy of its customers. We firmly believe this is an essential piece of legislation that is designed to strengthen and unify data protection laws for all individuals within the European Union.

Our engineers have been working closely with our lawyers, and we want to share with you some of the actions that we’ve taken to be compliant with the law:

• We’ve reviewed our data inventory to make sure we collect the minimum amount of personal data to run our business.
• We’ve reviewed and updated our security standards and ensured they are applied and meet the GDPR requirements.
• We’ve updated our privacy policy to provide more transparency surrounding our client’s personal data and to reflect our new requirements as data processor as well as your data protection rights.
• We will obtain assurances that all third-party service providers will safeguard your personal data in accordance with this policy and the European privacy laws.
• We’re offering a Data Processing Agreement (DPA), which enables our customers to comply with their GDPR obligations. Customers of GrapheneDB are free to request our standard DPA by reaching out to support@graphenedb.com from the email address associated with your GrapheneDB account. Please note that our DPA has been tailored to the way GrapheneDB provides its service, and as a result, changes to DPA language are not available at this time.

At GrapheneDB we’re not only committed to complying with GDPR but also aware that you will need to comply if you’re a business in the EU. We offer the following tools to help you with that:

• You can anytime modify, export or delete any record from the database using the available endpoints.
• You can permanently delete the content of a database by using the “empty database” feature. We’re going to very soon release a soft-delete feature for providing a clear and transparent policy on permanent deletion of backups and datasets.
• You can export complete datasets using the export database feature.
• We offer a wide range of regions where you can host your data.
• From our lowest free Sandbox plan, we offer strong security measures to protect the data in your databases, meeting the GDPR requirements. Additionally, on Performance and Enterprise databases, your data will be encrypted at rest, and you’ll be able to restrict the outbound traffic using Private Networks.

We hope this makes your use of GrapheneDB and the transition to GDPR much easier. Our customer support team will be happy to help you out with any GDPR or data security questions.

Juanjo and Alberto
Founders of GrapheneDB

As GrapheneDB continues to grow, we seek to increase value for our customers. We are excited to announce today new plans, pricing, and features!

We are adding support for new AWS regions, and making our pricing more consistent across regions. We are also adding new plans and tiers with lower prices and improved specs.

And lastly, we’re adding a couple of exciting features to enhance security: Private Networks and Encryption at rest. You can read more about all of these new, exciting changes below.

Summary of pricing changes

General improvements to plans and pricing

• More features available in certain plans (see Plans breakdown below)
• Better specs for lower prices in some plans or tiers
• We’re simplifying pricing by sticking to the lowest price across all supported AWS regions.
• We’re adding Ohio, Seoul and Mumbai to our long list of supported AWS regions. This means GrapheneDB now powers Neo4j deployments across 13 AWS regions!

Hobby databases

We have made following improvements:

• Include the Insights package that displays performance metrics and slow queries (with 1 hour data retention)
• Encryption in transit (SSL connections)
• The free Sandbox plan now supports Neo4j unmanaged extensions and stored procedures

Standard

• We are increasing the data retention of the Insights dashboard to analyze performance metrics and slow queries from 3 to 12 hours on all Standard plans
• We are introducing a new Standard S3 plan with 2GB of RAM (exclusively dedicated to Neo4j) at $200 per month

Performance

• All Performance plans have new upgraded specs, with the P1 plan now starting at 8GB of RAM (total VM memory, a small part is reserved for the OS)
• We’ve improved the disk I/O performance of the P2 and higher plans
• We’ve cut the prices of the P3 and higher plans by 25%

How do the new plans and pricing affect you?

New plans have been launched to replace old plans. These old plans are no longer available when provisioning new databases and will be renamed to include the word “Legacy” in the plan name. These Legacy plans will continue to be billed at the previous prices and will continue to have the same features as before.

To take advantage of the new plans, features, and prices, you will need to deploy new databases. Don’t worry! There is no rush to make this move. Existing databases will continue to run and we currently do not have a sunset date scheduled.

You are free to move to the new instances as soon as you want to take advantage of the price reductions or increased specs/features. To do so, you will need to clone the original instance on the Legacy plan into one of the new plans, point your app to the new instance, and then delete the old one. You can read more info on the cloning process in this section of our developer docs.

New features

Private Networks

In order to increase the security options available to our customers, we are introducing our new Private Network feature. Private Networks are dedicated network environments you can use to isolate your database(s) from public networks.

All new databases in the Performance and Enterprise tiers will now have the option to use a Private Network, which will allow you to completely restrict access via IP Whitelisting or VPC Peering. Alternatively, the network can be set to public access if needed for purposes such as testing. You can read more about how our Private Network feature works here.

Encryption at rest

Encryption at rest provides a layer of protection against unauthorized access to sensitive data. Disk volumes, data in transit between server instances, as well as disk volumes and backups will now have the option to use encryption at rest.

This means your data will now be encrypted using the industry standard AES-256 algorithm, which meets a comprehensive range of compliance standards, such as HIPAA, PCI and NIST. You can read more about encryption at rest and how to enable it here.

Wrapping up

We are really excited to announce our new pricing, plans, and new security features.

We remain committed to providing the best value and features for our customers, and as always, we are looking forward to hearing your feedback regarding these changes. If you have feedback or questions please contact us by submitting a new support ticket or via email at support@graphenedb.com.

We are excited to announce a new authentication system that has been rolled out to all GrapheneDB databases last week (Feb 14th 2017).

Background

Back in the days when we launched GrapheneDB in 2013, Neo4j did not support authentication.

Common patterns to deploy Neo4j included setting up a proxy to deal with SSL encryption and enforce HTTP basic authentication or installing an unmanaged server extension to take care of authentication.

We had to roll out our own authentication mechanism from scratch, if we were to provide a hosting service. From the beginnings until some days ago, we created a set of credentials including a random password upon database creation. These credentials would be up for display on the UI any time if the user needed them. This fact implied storing the credentials in plain text within our database.

Fast forward to 2015. In version 2.2.0, Neo4j introduced user management and secured the HTTP REST endpoint with HTTP basic authentication, which was at that point a standard for any Neo4j driver supporting authentication. Because HTTP basic authentication is a standard, our authentication was 100% transparent and compatible with all Neo4j drivers available.

Then, in Neo4j 3.0 user authentication was consolidated and integrated into the Bolt protocol as well. At GrapheneDB we implemented a Bolt-aware proxy layer, one of its purposes being to extend our authentication system to work with Bolt too.

Drawbacks of our legacy authentication system

The main drawbacks about GrapheneDB’s legacy authentication system come down to various risks related to, and ultimately the security of the database.

Exposing credentials

The credentials were stored in plain text in our database and up for display in the UI any time. It was easy to copy & paste credentials and accidentally expose them via unsafe channels: sending them in emails, posting them on Stackoverflow, on Github or in a support ticket.

We usually pay a lot of attention to this and reach out to users to rotate their credentials when we are aware that they have been exposed, but having credentials in front of you in plain text makes one automatically less concerned about protecting them.

Sharing credentials

When submitting support requests, our users have the option to allow GrapheneDB engineers to access their databases. In order to connect to a users’ database our engineers need valid credentials, so internally our engineers have been using the one set of credentials to connect.

While our engineers are very security concerned and well trained to never expose credentials, this is problematic in terms of auditing and might raise concerns with our users. As soon as a set of credentials is shared by several individuals, it becomes very challenging to keep track of who has copies of them and who might have used them to connect.

Credentials for one-off sessions

Another challenge is dealing with temporary connections. If you need to briefly connect to your Neo4j instance via Neo4j Browser or CLI, which credentials do you use?

It is extremely easy to accidentally store credentials in a web browser. In fact, most of modern browsers ask the user by default if they wish to store the credentials they have provided to log in.

When using CLI tools such as cycli, it is also extremely easy for credentials to land in your command line history. The history file is usually stored in plain text in your home directory, while the browsers at least tend to default to some sort of secure encryption to store credentials.

Our new secure and flexible authentication system

Our new authentication system addresses many of the issues with the legacy authentication system:

• it’s compatible with any Bolt and HTTP REST drivers that support authentication
• we only use strong passwords through lengthy, randomly generated tokens
• all tokens are stored encrypted and are only visible once upon creation. After that no one (not even our engineers) can retrieve a password
• should we need to connect to a user’s database (assuming we have been given permission by the owner) we will use specific internal temporary passwords that can be audited, not any of the database users
• plain text passwords have been removed from the interface and sharing passwords is discouraged, because it’s much easier for any team member to create database users as needed
• it supports temporary credentials for one-off connections, such as connecting from CLIs or with the Neo4j Browser
• users can drop and rotate credentials anytime: unused credentials, when someone leaves the team or if you think a secret might have been compromised or leaked

Making your GrapheneDB databases safer

We are very excited to improve the security for all our databases and ultimately our users. Moving forward:

• New databases support the new authentication system only, making them safer by default
• Existing databases will continue to support the legacy password system to authenticate. Create pairs of credentials as needed and drop the legacy password as soon as you can to make them safer. You will find clear step by step instructions to guide in the transition process here.

Managing database users

You can find more information on the new database authentication system in the dedicated section of our developer docs.

We are proud to announce support for the UK and Canada regions recently launched by AWS. Customers in these regions can now serve their end-users better through low network latencies and are able to store data in any of the two countries.

All our Standard, Performance and Enterprise plans are available for deployment in these two new regions.

Here is the updated list of regions GrapheneDB supports, by tiers.

Hobby:

• US East (N. Virgina)
• EU (Ireland)

Standard, Performance & Enterprise:

• US East (N. Virgina)
• US West (N. California)
• US West (Oregon)
• Canada (Central)
• EU (Ireland)
• EU (Frankfurt)
• EU (London)
• Asia Pacific (Tokyo)
• Asia Pacific (Singapore)
• Asia Pacific (Sydney)

We are excited to grow our list of supported regions and serve our world-wide customer base better. If you have any questions, please feel free to reach out to us.