> ## Documentation Index
> Fetch the complete documentation index at: https://specterops-bed-7559-api-key-exp.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenGraph Requirements

> Requirements for using OpenGraph

<img noZoom src="https://mintcdn.com/specterops-bed-7559-api-key-exp/Q9Jppg_Pu54SydxZ/assets/enterprise-AND-community-edition-pill-tag.svg?fit=max&auto=format&n=Q9Jppg_Pu54SydxZ&q=85&s=dab889e863a05e09b1378befc30bbb10" alt="Applies to BloodHound Enterprise and CE" width="482" height="45" data-path="assets/enterprise-AND-community-edition-pill-tag.svg" />

# Version Requirements

Full OpenGraph support requires a PostgreSQL graph database and one of the following editions:

* BloodHound Enterprise (uses PostgreSQL by default)
* BloodHound Community v8.0.0+ (requires  changing to a [PostgreSQL database](/get-started/custom-installation#postgresql))

  <Note>
    While many OpenGraph features may work on a Neo4j database, there are functional and performance limitations (see the [OpenGraph FAQ](/opengraph/faq#why-is-it-taking-so-long-to-ingest-opengraph-data)). For full support, migrate to a PostgreSQL database.
  </Note>

# Graph Requirements

## Requirement 1: Universally Unique Node Identifiers

Every node in a BloodHound database must have a universally unique identifier to distinguish it from every other node. You must identify the source and format of that identifier.

We previously used UPN-formatted names for identifiers in BloodHound (e.g.: “DOMAIN [ADMINS@CONTOSO.COM](mailto:ADMINS@CONTOSO.COM)”). Surprise surprise, UPNs are not guaranteed to be universally unique. We now use SIDs instead for universally unique identifiers for most Active Directory principals.

One of the best universally unique identifiers is a GUID. Does the entity you are modeling have a GUID? If so, great! If not, you’re going to need to find something else.

Examples of **bad** identifiers:

* Usernames
* Email addresses
* Hostnames
* IDs that start at “0” and increment from there

Examples of **good** identifiers:

* GUIDs
* SIDs
* Certificate thumbprints

Think: how does the system itself differentiate between these objects? In many (but certainly not all) cases, you may do well to identify your nodes the same way the system uniquely identifies its objects.

## Requirement 2: Distinct Node and Edge Classes

If you are modeling a new system not currently modeled by BloodHound, your nodes and edges must have distinct classes that do not overlap with existing BloodHound node and edge classes.

Sorry, but “MemberOf” is already taken, so you will need to use a different edge class when modeling group memberships in Okta, Zoho, AWS, or whatever else. Same with all the other existing node and edge classes which can be found here:

* [About BloodHound Nodes](https://bloodhound.specterops.io/resources/nodes/overview)
* [About BloodHound Edges](https://bloodhound.specterops.io/resources/edges/overview)

## Requirement 3: Your Model Must Connect Non-Adjacent Nodes with Paths

If your graph model does not create **paths** connecting **non-adjacent** nodes, you should be using a **relational database**, not a **graph database**. You are using the **wrong** tool for the job!

## Requirement 4: Edge Names and Allowed Characters

Edge names may only contain alphanumeric characters and underscores (`_`).

For readability, we recommend PascalCase, a naming convention where compound words are written without spaces and each word starts with an uppercase letter (e.g., `MemberOf`, `GenericAll`).