What HydraDB Promises at the Edge: Queries, Limits, and Operations
HydraDB's architecture becomes meaningful to a user at its public boundary: a Bolt or HTTP request is authenticated, tied to a graph scope, admitted under limits, executed against a chosen read view or writer, and returned as rows, a cursor, or a bookmark. This chapter examines that contract rather than treating the client API as a thin wrapper around storage. The goal is to show how query-language boundaries, consistency choices, resource budgets, security controls, and operational signals turn HydraDB's internal authority model into observable behavior.
A system can have durable records and careful fencing yet still be difficult to operate if clients cannot tell what a request means or how much work it may create. HydraDB responds by making several choices explicit. It supports an executable subset of OpenCypher instead of silently accepting every form. It classifies a request before granting read or write access. It binds authentication and authorization to the target namespace, graph, and cell. It uses bookmarks and strong reads for different freshness needs, and it retains paged results in bounded state rather than rerunning a changed query without warning.
A bounded language is part of the design
HydraDB is not presented as a full implementation of every OpenCypher construct. Its supported surface includes directed typed patterns, bounded variable-length paths, property predicates, selected projections and aggregates, ordering, pagination, selected mutations, parameter-driven UNWIND batches, read unions, and the native path procedures. The common thread is that the server can lower the form into an execution path with a known shape and a clear relationship to the graph's storage model.
The unsupported side is equally informative. Unbounded variable-length traversal, undirected or multi-type relationship patterns, broad forms of WITH, unsupported predicates or aggregates, mixed or nested unions, multiple statements, and other constructs outside the implemented subset are rejected at parse time with a reason. A request such as an unbounded traversal is not accepted merely to discover later that a large graph makes it too expensive. Rejection makes the boundary visible before the server has committed to an uncontrolled execution plan.
This is an architectural choice, not a claim that the subset is a defect-free substitute for every Neo4j query. HydraDB supports Neo4j-driver-compatible Bolt connectivity and routing, but the repository itself documents direct-node and routed behavior separately and lists language constructs that are not executable. Client compatibility therefore means “the supported protocol and query contract work together,” not “all queries written for another graph database will run unchanged.”
The transport boundary also affects batching. A parameter-driven UNWIND operation carries a list of maps, so it is resolved through the client service that understands transport-level values. The in-process shard API carries scalar parameters and rejects those batch forms even when the Cypher shape itself is supported. That distinction is useful when diagnosing an error: a valid batch sent through the wrong entry point is a boundary mismatch, not necessarily a malformed graph operation.
A statement is parsed once and cached where the service can reuse the parsed form. But parsing and authorization are not the same action. The service classifies the request as a read or write and then authorizes that action against the target scope. A cached parse can be reused; permission is still checked for the current session and request. This keeps language recognition from becoming an accidental access grant.