Creates a new edge in the database.


CREATE EDGE <class> [CLUSTER <cluster>] [UPSERT] FROM <rid>|(<query>)|[<rid>]* TO <rid>|(<query>)|[<rid>]*
                    [SET <field> = <expression>[,]*]|CONTENT {<JSON>}
                    [RETRY <retry> [WAIT <pauseBetweenRetriesInMs]] [BATCH <batch-size>]
  • <class> Defines the class name for the edge. Use the default edge class E in the event that you don't want to use sub-types.
  • <cluster> Defines the cluster in which you want to store the edge.
  • UPSERT (since v 3.0.1) allows to skip the creation of edges that already exist between two vertices (ie. a unique edge for a couple of vertices). This works only if the edge class has a UNIQUE index on out, in fields, otherwise the statement fails.
  • JSON Provides JSON content to set as the record. Use this instead of entering data field by field.
  • RETRY Define the number of retries to attempt in the event of conflict, (optimistic approach).
  • WAIT Defines the time to delay between retries in milliseconds.
  • BATCH Defines whether it breaks the command down into smaller blocks and the size of the batches. This helps to avoid memory issues when the number of vertices is too high. By default, it is set to 100. This feature was introduced in version 2.1.3.

Edges and Vertices form the main components of a Graph database. OrientDB supports polymorphism on edges. The base class for an edge is E.

Beginning with version 2.1, when no edges are created OrientDB throws a OCommandExecutionException error. This makes it easier to integrate edge creation in transactions. In such cases, if the source or target vertices don't exist, it rolls back the transaction. (Prior to 2.1, no such error is thrown.)


  • Create an edge of the class E between two vertices:

    orientdb> CREATE EDGE FROM #10:3 TO #11:4
  • Create a new edge type and an edge of the new type:

    orientdb> CREATE EDGE E1 FROM #10:3 TO #11:4
  • Create an edge in a specific cluster:

    orientdb> CREATE EDGE E1 CLUSTER EuropeEdges FROM #10:3 TO #11:4
  • Create an edge and define its properties:

    orientdb> CREATE EDGE FROM #10:3 TO #11:4 SET brand = 'fiat'
  • Create an edge of the type E1 and define its properties:

    orientdb> CREATE EDGE E1 FROM #10:3 TO #11:4 SET brand = 'fiat', name = 'wow'
  • Create edges of the type Watched between all action movies in the database and the user Luca, using sub-queries:

    orientdb> CREATE EDGE Watched FROM (SELECT FROM account WHERE name = 'Luca') TO 
              (SELECT FROM movies WHERE type.name = 'action')
  • Create an edge using JSON content:

    orientdb> CREATE EDGE E FROM #22:33 TO #22:55 CONTENT { "name": "Jay", 
              "surname": "Miner" }

For more information, see

Control Vertices Version Increment

Creating and deleting edges causes OrientDB to update versions involved in the vertices. To avoid this behavior, use the Bonsai Structure.

By default, OrientDB uses Bonsai as soon as it reaches the threshold to optimize operation. To always use Bonsai on your database, either set this configuration on the JVM or in the orientdb-server-config.xml configuration file.

$ java -DridBag.embeddedToSbtreeBonsaiThreshold=-1

Alternatively, in your Java application use the following call before opening the database:


For more information, see Concurrency on Adding Edges.

NOTE When running a distributed database, edge creation can sometimes be done in two steps, (that is, create and update). This can break some constraints defined in the Edge at the class-level. To avoid such problems, disable the constraints in the Edge class. Bear in mind that in distributed mode SB Tree index algorithm is not supported. You must set ridBag.embeddedToSbtreeBonsaiThreashold=Integer.Max\_VALUE to avoid replication errrors



  • Disables Lightweight Edges in new databases by default. This command now creates a regular edge.


  • Command uses the Blueprints API. If you are in Java using the OGraphDatabase API, you may experience some differences in how OrientDB manages edges.

    To force the command to work with the older API, change the GraphDB settings, as described in Graph backwards compatibility.


  • Implements support for query and collection of Record ID's in the FROM...TO clause.


  • Initial version.

results matching ""

    No results matching ""