index.html.md.erb

---
title: Neo4j Enterprise for VMware Tanzu (Beta)
owner: Partners
---

<strong><%= modified_date %></strong>

<p class="note warning">
<strong>Warning: </strong>
Neo4j Enterprise for VMware Tanzu is currently in beta and is intended for evaluation and test purposes only.
Do not use this product in a PKS production environment.
</p>

This documentation describes Neo4j Enterprise for VMware Tanzu, which allows users to deploy multi-node
Neo4j Enterprise Causal Clusters to PKS instances, with configuration options
for the most common scenarios.  It represents a very rapid way to get started running a native graph database on top of Kubernetes.

## <a id='overview'></a>Overview

Neo4j is the world's leading native graph database which offers high performance ACID transactions
for graph management.  Users can deploy Neo4j to store and query their graphs using the Cypher query language.

Creating a Neo4j Enterprise for VMware Tanzu instance creates multiple StatefulSets in your Kubernetes instance backed by
persistent volume claims, which store the data.

This guide is intended only as a supplement to the
[Neo4j Operations Manual](https://neo4j.com/docs/operations-manual/3.5/?ref=pivotal-pks).
Neo4j Enterprise for VMware Tanzu is essentially a docker container based deploy of Neo4j Causal Cluster.
As such, all of the information in the Operations Manual applies to its operation,
and this guide will focus only on kubernetes-specific concerns and
PKS-specific concerns.

## <a id='features'></a>Key Features

Neo4j Enterprise for VMware Tanzu includes the following key features:

* Native graph database supports transactional applications and graph analytics
* Graph analytics help data scientists gain new perspectives on data
* The Cypher graph query language is the bridge to big data analytic tooling
* Graph visualization and discovery help communicate graph technology benefits throughout the organization

## <a id="snapshot"></a>Product Snapshot

The following table provides version and version-support information about PRODUCT-NAME.

<table class="nice">
    <th>Element</th>
    <th>Details</th>
    <tr>
        <td>Tile version</td>
        <td>v3.5.7</td>
    </tr>
    <tr>
        <td>Release date</td>
        <td>July 12, 2019</td>
    </tr>
    <tr>
        <td>Neo4j Enterprise component version</td>
        <td>3.5.7</td>
    </tr>
    <tr>
        <td>Compatible VMware PKS version(s)</td>
        <td>1.2, 1.3, 1.4</td>
    </tr>
    <tr>
        <td>IaaS support</td>
        <td>Any/all</td>
    </tr>
</table>


## <a id="reqs"></a>Requirements

Before installing Neo4j into your PKS cluster, confirm the following:

- You should have Docker and kubectl installed locally from the machine where you want to use neo4j
- You have authenticated Pivotal's CLI tools VMware PKS) locally to your account.
- You have run `pks get-credentials <cluster>` to configure your local kubectl client to interact with your PKS cluster.
- You should verify that you hold an existing Neo4j Enterprise license, whether purchased via the startup program, or on an evaluation basis.

## <a id="limitations"></a>Limitations

At present, bolt+routing drivers which attempt to connect to the cluster from outside of Kubernetes
will not function as expected.  Bolt+routing can be used from within the cluster though.  The reason
for this has to do with network address translation between the private DNS addresses of the database
nodes inside the cluster, and the inability for external clients to resolve those addresses.

For more information on this point, see [Neo4j Considerations in Orchestration Environments](https://medium.com/neo4j/neo4j-considerations-in-orchestration-environments-584db747dca5).

If your use case requires the need to access Neo4j with bolt+routing from outside of Kubernetes, we
recommend that you assign externally valid DNS to each of your nodes, and then configure the nodes to
advertise that external DNS.  In this way, bolt+routing from outside of Kubernetes can be made to work,
after configuring ingresses to permit network traffic to enter the cluster.

Exposing each individual pod to a distinct external port is another option, but users who take this
“port spreading” approach should be careful to keep in mind the cluster topology; i.e. only the cluster
leader may accept writes, but any bolt endpoint may be used to spread out read queries.

## <a id="feedback"></a>Feedback

If you have a feature request, questions, or information about an issue, please email send an email to [support@neo4j.com](mailto:support@neo4j.com).

## <a id='license'></a>License

Neo4j Enterprise for VMware Tanzu is available to any existing enterprise license holder of Neo4j in a Bring Your Own
License (BYOL) arrangement.  Neo4j Enterprise for VMware Tanzu is also available under evaluation licenses, contact
Neo4j in order to obtain one.   There is no hourly or metered cost associated with using Neo4j Enterprise for VMware Tanzu for current license holders.