Projects / Multi-Model Databases
Subproject
ArcadeDB Embedded Python
A Python-facing distribution built on top of the original Java-based ArcadeDB, with native bindings, embedded execution, and a cleaner path to graph, vector, and multi-model workloads from Python.
Distribution
Turn the original Java-based ArcadeDB into a Python-native distribution.
Figure 1
Packaging stack
- Original Java-based ArcadeDB engine
- Bundled JRE per supported platform
- Native Python bindings
- Wheel-based Python distribution
The original ArcadeDB project is powerful, but its Java-first setup creates friction for Python developers who want to install it like a package, run it locally, and embed it directly inside application workflows.
ArcadeDB Embedded Python exists to remove that friction. It keeps the upstream ArcadeDB engine at the core, then repackages it for Python with native bindings, platform-specific wheels, and a bundled JRE so Python users can start from a familiar packaging model.
Runtime
Use ArcadeDB locally, in process, and without separate setup steps.
Figure 2
Runtime modes
- Embedded in-process database usage
- Optional server mode when needed
- CI-validated examples and tests
- Linux and macOS wheel targets
The main value is not just access to ArcadeDB from Python, but access in a form that fits local tooling, tests, and embedded application code. Developers should be able to install the package and start using the database without first setting up a separate Java environment or standalone service.
Optional server mode is still there when it helps, but the project is intentionally optimized around in-process embedded usage from Python workflows.
Surface
Expose a real Python package surface instead of a thin wrapper.
Figure 3
Python package surface
- Transactions and lifecycle management
- Schema and graph helpers
- Export and import paths
- Vector and multi-model features
This subproject is not just a launcher around the upstream engine. It exposes transactions, schema management, graph helpers, export paths, and vector-related capabilities as a maintained Python package surface.
That is the real reason it exists as a standalone subproject: to make ArcadeDB feel like a usable Python dependency rather than a one-off interoperability experiment.
Resources