Why sftp.cloud needed its own distributed database...
And SyngoDB wasn't the wrong answer. It was the answer to a different question.
A few days ago, we announced sftp.cloud. An inverted control/data plane for your cloud SFTP head. Outbound-only storage connectors. No files ever stored in our cloud. If you haven’t read that post yet, it’s worth your time before reading this one.
Since then, several of you have asked what the backend of something like sftp.cloud actually runs on. Connector registration, session routing, access policy distribution, audit records, configuration replication across geographically dispersed nodes. That is a lot of operational state that must stay available, consistent, and survivable across node failures, regional outages, and network partitions.
SyngoDB is our embedded document database. It backs Syncplify Server!, R2FS!, and AFT!, handling configuration, metadata, and operational state reliably and fast. It supports optional RAFT-backed replication for multi-node deployment.
But sftp.cloud is a different beast.
RAFT is a CP system. Under a partition, the minority side stops accepting writes. In a single-datacenter cluster, that trade-off is entirely reasonable. But when your nodes are spread across multiple regions, “wait for a majority” imposes real write latency on a healthy cluster, and an isolated region stops accepting writes entirely until the partition heals.
That is not the operational model sftp.cloud requires.
Introducing GeoSyngoDB
GeoSyngoDB is the AP-first distributed document database that we designed and developed to power sftp.cloud.
AP-first is not a euphemism. Under the CAP theorem you cannot have Consistency, Availability, and Partition tolerance simultaneously. We deliberately chose Availability and Partition tolerance over global real-time Consistency. Reads and writes succeed on any healthy, reachable node even during a partition failure. The cluster converges to consistency once the partition heals. For sftp.cloud’s operational data model, that trade-off is correct.
Data is distributed across nodes using a token ring with no leader and no single coordinator. Writes go to a configurable number of replica nodes, selected from a topology-aware preference list that tracks each node’s datacenter, region, and VLAN, spreading replicas across failure domains before falling back to same-location nodes. When a replica is temporarily unreachable, its mutations are delivered once the node recovers. Background anti-entropy workers and passive read-repair keep replicas converging continuously after failures, re-partitioning, and topology changes. Membership is gossip-based: nodes discover and monitor each other without editing configuration files on every peer.
The icing on the cake? The local storage engine underneath all of this is still an embedded SyngoDB. GeoSyngoDB does not reinvent its document storage, indexing, or compaction. It delegates all of that to the same layer that backs our other products, keeping the physical storage layout clean and the I/O paths separate per namespace.
What it means for you as an sftp.cloud user
The infrastructure behind sftp.cloud’s control plane runs on a purpose-built, geographically distributed document store that we understand completely, because we wrote every line of it for this exact workload.
Session metadata, connector registry, access policies, and audit records live in a system that stays available through regional outages and network partitions, converges automatically after failures, and has no single point of failure anywhere in its data plane. No third-party SaaS database in the critical path. No opaque failure modes. No service agreement as a load-bearing architectural dependency.
sftp.cloud is not finished. But when it ships, the database layer underneath it will have been designed, built, tested, and benchmarked specifically for this workload.
Not borrowed. Not vibe-coded. Not bolted in. Built.