GoKawiilUntil now, talking to ArcadeDB from Python or Node meant one of two things: writing HTTP calls by hand against the REST API, or borrowing a driver built for another database and living inside the subset of ArcadeDB that other database’s protocol happens to expose. Both work. Neither is a client anyone would call native.
That changes with arcadedb-drivers, a new repository holding four published clients: an HTTP driver and a gRPC driver for Python, and an HTTP driver and a gRPC driver for TypeScript/JavaScript. All four are Apache-2.0, all four are generated from contracts ArcadeDB itself publishes, and all four are on the public registries today. They are also young: 0.1.0 releases under heavy development, with more languages on the way.
The four packages
Package Language API Install arcadedb-driver Python HTTP pip install arcadedb-driver arcadedb-driver-grpc Python gRPC pip install arcadedb-driver-grpc @arcadedb/driver TypeScript/JS HTTP npm install @arcadedb/driver @arcadedb/driver-grpc TypeScript/JS gRPC npm install @arcadedb/driver-grpc
All four talk to a running server, so they assume the client-server deployment rather than the embedded one. The Python packages need Python 3.10 or newer. The TypeScript packages need Node 20 or newer and are ESM only: import them, do not require() them. Version 0.1.0 of each targets ArcadeDB server 26.9.1, and every package README carries a compatibility table mapping driver versions to server versions.
HTTP or gRPC?
Two drivers per language is not indecision. HTTP and gRPC are the two transports ArcadeDB speaks, and each handles some workloads better than the other.
Use the HTTP driver when Use the gRPC driver when You are writing browser code You are writing server-to-server code You want the fewest dependencies You are reading a large result set and want to stream it You are in a serverless function with cold starts to worry about You are bulk-inserting and want one long-lived connection Your traffic is ordinary request/response Your traffic is throughput-sensitive and sustained You want to reuse existing HTTP infrastructure: proxies, gateways, tracing You want native bidirectional streaming
Start with HTTP. It works everywhere, it needs nothing beyond fetch or httpx , and for most application traffic the protocol is not the bottleneck. Move a workload to gRPC when you can point at the throughput number that justifies it.
One constraint is easy to lose an afternoon to, so here it is plainly. There is no browser build of the gRPC driver, and there will not be one until the server changes. ArcadeDB’s GrpcServerPlugin is plain grpc-java over HTTP/2, built on Netty, with no gRPC-Web handler, no Connect protocol, and no servlet adapter in front of it. A browser cannot speak raw HTTP/2 gRPC framing, so no client library in any language can reach this server from a browser tab. Browser code uses the HTTP driver. The limit is in the server.
... continue reading