Setting UP Arcade DB for production.

[varun0591-stack]

We are going through Arcade DB and now thinking to build its infra in cloud and deploy it.
We are still thinking whether to go with docker setup or binary setup. Let me know if you have some opinion around it ?
I Need idea some idea how I can configure replication factor which using multiple region clusters. Where are cluster can serve as active active.
Also do I need to implement partitioning/sharding feature from our side or do Arcade db provide this ?

[lvca]

Hi @varun0591-stack, thanks for considering ArcadeDB for production. Let me take your questions one at a time.

Docker vs. binary

Both are fully supported in production - it's mostly an operational preference:

• Docker is the easiest path if you already run on Kubernetes or a container platform. Just remember to mount the databases/ directory (and your config) on persistent storage, set the JVM heap and the arcadedb.* settings via environment variables, and pin a specific image tag rather than latest.
• Binary / tarball gives you more direct control over the JVM, OS-level tuning (huge pages, file descriptors, NUMA), and systemd integration. It's a good fit on dedicated VMs.

For most cloud deployments I'd suggest Docker for the simpler lifecycle, unless you have specific host-level tuning needs.

Replication / high availability

ArcadeDB ships with built-in HA based on a Raft consensus model:

• It is leader-based, not multi-master. At any time one node is the leader that accepts writes; the others are replicas. Replicas can serve reads, and a write sent to a replica is transparently forwarded to the leader. So you get active-active for reads and single-writer for writes, with automatic failover (a new leader is elected if the current one goes down).
• There is no separate "replication factor" knob - every node holds a full copy of the database. The number of replicas is simply the number of servers you put in the cluster.
• Key settings:
  • arcadedb.ha.enabled=true
  • arcadedb.ha.serverList - the cluster members as host:raftPort:httpPort[:priority], comma-separated. The optional priority lets you bias which node becomes leader.
  • arcadedb.ha.quorum - majority (default, standard Raft) or all.
  • arcadedb.ha.serverRole=replica - pins a node as a never-leader read replica (handy for read scaling or a witness node).

About multi-region active-active: because writes need a Raft quorum, cross-region write latency is the thing to watch - every write waits for acknowledgements from a majority of nodes, so spreading voting members across distant regions adds round-trip latency to each commit. Common patterns:

• Keep the voting/leader-eligible nodes within one region (or close regions) and put serverRole=replica read replicas in remote regions for low-latency local reads.
• If you run a WAN cluster, bump arcadedb.ha.electionTimeoutMin / electionTimeoutMax to avoid spurious elections from network jitter.

True multi-master where any region accepts writes independently is not something ArcadeDB does today.

Partitioning / sharding

A couple of things to clarify here:

• ArcadeDB partitions each type into multiple buckets automatically. Buckets give you intra-server parallelism (parallel scans, parallel ingestion) and you can route inserts to specific buckets. This is built in - you don't implement it yourself.
• However, ArcadeDB does not currently do automatic horizontal sharding across servers (i.e., splitting one dataset so each node holds only a slice). In HA mode every server holds the complete database. So you scale reads horizontally by adding replicas, and you scale writes/storage vertically on the leader.

If your dataset is expected to exceed what a single node can hold, that's worth designing around early - feel free to share your expected data volume and read/write ratios and we can advise further.

Hope this helps - happy to go deeper on any of these.

[jcmfernandes]

Hi @lvca. Is single-master per database instead of per cluster something you plan to work on in the near future? What about replication factor? Thank you.

[lvca]

It's much easier to handle replication per server instead of per database (leader/follower). Unless there is a big demand on this, we're good with the current architecture. With replication factor, do you mean the quorum or the number of copies of each shard? In this case ArcadeDB always replicates to all the servers, we don't have the sharding concept like Dynamo/Cassandra