A geospatial database for fleet tracking and location data
ArcherDB stores location events for moving vehicles and assets and answers questions about where they are. It is built for teams that run fleet, logistics, and delivery systems on their own infrastructure.
What it does
ArcherDB takes in location events for entities such as vehicles, containers, or equipment. It indexes each event by place, keeps the event history, and tracks the latest position of every entity. Applications read the data through client libraries.
- Radius queries. Find events within a set distance of a point.
- Polygon queries. Find events inside a boundary, including boundaries with excluded areas cut out of them.
- Latest position. Read the newest position for one entity or for a batch of entities.
- Lookup by ID. Fetch events for one entity or a batch of entities by identifier.
- Write and delete. Insert or upsert location events, and delete an entity's records by identifier.
- Retention. Set expiry on events so old data ages out.
Who it is for
ArcherDB suits teams building fleet management, asset tracking, delivery, and logistics products that need location queries from one system. It fits teams that run their own infrastructure and can place network and access controls around the database.
How it works
- An application sends location events through a client library.
- The primary replica puts the events in order and sends them to the other replicas.
- Once a majority of replicas confirm, the events are committed and the client gets a reply.
- The events are written to log-structured storage, indexed by spatial cell, and the entity's latest position is updated in memory.
- A radius or polygon query looks up the matching cells, then checks each candidate against the exact shape.
What it is built for
ArcherDB runs as a group of replicas that agree on the order of writes. If the primary replica fails, the remaining replicas choose a new one. A second region can follow the first through asynchronous replication, so a follower region can be behind. Moving to a follower region after a regional failure is a manual step.
- Backup. Built-in continuous upload to local or cloud object storage. Scheduling and retention stay with the operator.
- Operations. Metrics, tracing, logging, a command-line tool, and graceful shutdown.
What it leaves to your infrastructure
By design, ArcherDB assumes a trusted network. It has no built-in authentication, authorization, or TLS, and the server does not encrypt its data files. You enforce those controls at your gateway, your network, and your storage layer, and you keep database ports off the public internet. If you want help placing those controls, see our security review.
Capacity profiles
ArcherDB comes in five profiles: Lite, Standard, Pro, Enterprise, and Ultra. Lite is for demos and evaluation and has intentionally limited storage. The other four are production profiles that share one runtime and differ in memory and storage capacity. ArcherDB is a commercial product, and access is set by a written agreement. To talk through a fit, contact us.
ArcherDB FAQ
Which languages have client libraries?
C, Go, Java, Node.js, and Python. All five support the same list of operations.
Does ArcherDB handle login and encryption?
No. It leaves authentication, authorization, TLS, and encryption at rest to your gateway, network, and storage platform. The documentation says to keep it on a trusted private network.
What happens when a node fails?
The remaining replicas elect a new primary, and writes continue as long as a majority of replicas are available.
Can I back up the data?
Yes. ArcherDB can upload data continuously to local or cloud object storage. You schedule and manage retention yourself, and platform snapshots are recommended alongside.
Can it run in more than one region?
Yes. A follower region can replicate from the primary region asynchronously. The follower can lag, and promoting it after a regional failure is a manual step.