OrientDB Importer

Migrating from OrientDB? The ArcadeDB Academy offers a free course on OrientDB-to-ArcadeDB migration with hands-on exercises and a certification at the end.

ArcadeDB is able to import a database exported from OrientDB in JSON format.

For more information about how to export a database from OrientDB, look at Export Database.

To import a database use the Import Database command from API, Studio or Console. Below you can find an example of importing a OrientDB database by using ArcadeDB Console.

> CREATE DATABASE MyDatabase
{MyDatabase}> IMPORT DATABASE file:///temp/orientdb-export.tgz

Differences with OrientDB

ArcadeDB was created from the same original developers of OrientDB, but it was built from scratch with a completely new codebase and architecture. While many concepts will feel familiar to OrientDB users, there are important differences to be aware of when migrating.

Architecture

No classes hierarchy: ArcadeDB uses Types instead of Classes. Types support single inheritance but do not support the polymorphic class hierarchy that OrientDB offered.
Buckets instead of Clusters: What OrientDB called "clusters" are called "buckets" in ArcadeDB. They serve a similar purpose of physically grouping records, but the API and behavior differ.
No Record-level security: ArcadeDB does not implement record-level security. Security is managed at the database and server level.
Embedded only or Client-Server: ArcadeDB runs either as an embedded database or in client-server mode. There is no "remote" storage engine concept as in OrientDB.
Component-based storage: ArcadeDB uses an LSM-Tree based storage engine, which is fundamentally different from OrientDB’s plocal/memory storage engines.

Data Model

No BLOB/Binary type: ArcadeDB does not have a dedicated BLOB or ORecordBytes type. Binary data should be stored as Base64-encoded strings or managed externally.
No LINKBAG: ArcadeDB uses simpler edge management for graphs and does not use the LINKBAG (ridbag) structure.
No CUSTOM field type: The CUSTOM field type from OrientDB is not available.
No embedded geometry types: ArcadeDB has no OPoint, OLineString, or OPolygon embedded types. Geometries are stored as WKT strings in STRING properties (see Geospatial Data below).
Record IDs: ArcadeDB uses Record IDs (RIDs) with the same #bucket:position format, but the internal storage is different.

Geospatial Data (OPoint and other spatial types)

OrientDB’s spatial module stored geometries as embedded documents of dedicated classes such as OPoint, OLineString, and OPolygon, each with a coordinates field. ArcadeDB has no embedded geometry type: geometries are stored as a plain STRING property containing the geometry in Well-Known Text (WKT) format, and are queried with the built-in geo.* SQL functions (backed by JTS and Spatial4j). See Geospatial Index for the full reference.

Both engines use the same axis order, longitude first then latitude (the GeoJSON/WKT convention), so coordinate values migrate directly without swapping.

OrientDB ArcadeDB

	OrientDB	ArcadeDB
Storage	Embedded `OPoint` with `coordinates: [lon, lat]`	`STRING` property with WKT: `POINT (lon lat)`
Construction	`ST_GeomFromText('POINT(12.5 41.9)')`	`geo.point(12.5, 41.9)` or the literal WKT string
Functions	`ST_*` (e.g. `ST_Distance`, `ST_Within`)	`geo.*` (e.g. `geo.distance`, `geo.within`)
Index	Lucene spatial index	`CREATE INDEX … GEOSPATIAL` (see Creating a Geospatial Index)

Storage

Embedded OPoint with coordinates: [lon, lat]

STRING property with WKT: POINT (lon lat)

Construction

ST_GeomFromText('POINT(12.5 41.9)')

geo.point(12.5, 41.9) or the literal WKT string

Functions

ST_* (e.g. ST_Distance, ST_Within)

geo.* (e.g. geo.distance, geo.within)

Index

Lucene spatial index

CREATE INDEX … GEOSPATIAL (see Creating a Geospatial Index)

To migrate OPoint data:

Define the target property as STRING:
```
CREATE PROPERTY City.location STRING
```
Convert each OPoint to WKT on insert. An OrientDB export serializes an OPoint as {"@class":"OPoint","coordinates":[12.5,41.9]}; map coordinates[0] to longitude (x) and coordinates[1] to latitude (y):
```
INSERT INTO City SET name = 'Rome', location = 'POINT (12.5 41.9)'
-- or build it from the coordinates programmatically:
INSERT INTO City SET name = 'Rome', location = geo.point(12.5, 41.9)
```
Create a geospatial index (used automatically by geo.within and geo.intersects):
```
CREATE INDEX ON City (location) GEOSPATIAL
```

Translate ST_* queries to their geo.* equivalents:

-- distance with the Haversine formula (unit: 'km' default, or 'm')
SELECT geo.distance(location, geo.point(12.49, 41.90), 'km') AS dist_km FROM City

-- containment / proximity (index-accelerated). geo.buffer distance is in degrees
-- (~0.01 deg ≈ 1.1 km at the equator)
SELECT FROM City WHERE geo.within(location, geo.buffer(geo.point(12.5, 41.9), 0.01)) = true

The same pattern applies to other OrientDB spatial types: use geo.lineString(…) for OLineString and geo.polygon(…) for OPolygon, or insert the corresponding LINESTRING (…) / POLYGON … WKT directly. Use geo.x() / geo.y() to extract raw coordinates (for example to validate migrated values against the originals) and geo.asGeoJson() for GeoJSON output.

SQL

Mostly compatible: ArcadeDB SQL is largely compatible with OrientDB SQL, with some differences:
- LET blocks in queries have some syntax differences.
- TRAVERSE is supported but deprecated in favor of MATCH and recursive queries.
- The .asSet(), .asList(), .asMap() methods are kept for OrientDB compatibility.
- DELETE … UNSAFE is kept only for compatibility but has no effect.
- Some OrientDB-specific functions may not be available.
New SQL extensions: ArcadeDB adds SQL commands not found in OrientDB, such as ALIGN DATABASE, IMPORT DATABASE with multiple format support, and enhanced MATCH syntax.

API

No ODocument/OVertex/OEdge: ArcadeDB has its own API with Document, Vertex, and Edge interfaces that are similar in concept but different in implementation.
No ODatabaseDocument: Use Database or DatabaseFactory in ArcadeDB.
No OClass: Use DocumentType, VertexType, and EdgeType instead.
Multi-model API: ArcadeDB provides a unified multi-model API from the start, supporting Document, Graph, Key/Value, Search Engine, Time Series, Vector, and Geospatial models.

Connectivity

HTTP/JSON API: ArcadeDB provides a REST API that is different from OrientDB’s REST API. The endpoints and JSON format are not compatible.
Postgres wire protocol: ArcadeDB supports the PostgreSQL wire protocol, allowing connections from any PostgreSQL-compatible client. OrientDB did not offer this.
MongoDB wire protocol: ArcadeDB supports the MongoDB wire protocol natively.
Redis wire protocol: ArcadeDB supports a subset of the Redis protocol.
Bolt protocol: ArcadeDB supports the Neo4j Bolt protocol, enabling connections from Neo4j-compatible clients and drivers.
gRPC protocol: ArcadeDB supports gRPC for high-performance client-server communication.
No binary protocol: ArcadeDB does not use a custom binary protocol like OrientDB’s. Instead, it relies on HTTP/JSON and standard database wire protocols (PostgreSQL, MongoDB, Redis, Bolt, gRPC).
Gremlin: ArcadeDB supports Apache TinkerPop Gremlin, similar to OrientDB, but through an embedded Gremlin engine rather than as a TinkerPop server.

Migration

To migrate from OrientDB to ArcadeDB:

Export from OrientDB: Export your OrientDB database using the OrientDB console EXPORT DATABASE command in JSON format.
Import into ArcadeDB: Use the ArcadeDB OrientDB Importer or the IMPORT DATABASE SQL command:
```
IMPORT DATABASE url=file:///path/to/orientdb-export.json.gz
```
Update application code: Adapt your application to use ArcadeDB’s API, drivers, and connection protocols.
Test thoroughly: Verify that queries, data integrity, and application logic work correctly with ArcadeDB.

For more details on importing, see the OrientDB Importer section.