SyngoDB just got a lot faster
The database engine behind Syncplify products received a focused performance upgrade, without changing its stability contract
Most Syncplify users never interact with SyngoDB directly. That’s by design.
SyngoDB is not a separate product you install, configure, and babysit. It is the embedded database layer used internally by Syncplify software products to store and retrieve configuration, metadata, operational state, and other product data that must be durable, consistent, and fast.
In other words, SyngoDB is one of those components you only notice if it fails. And it doesn’t.
That said, a lot of product behavior eventually depends on this hidden layer: searches, sorted views, paginated results, metadata scans, state lookups, configuration reads, index maintenance, and a long list of small operations that happen constantly while the visible product is doing its job.
So we recently completed a focused performance sprint on SyngoDB.
The goal was simple: make it faster and more memory-efficient where it matters, without compromising the things that matter more.
And yes, that second part is important.
Performance work in a database is not like performance work in a stateless utility function. You don’t get to “optimize” by casually skipping copies, weakening consistency, changing key formats, or introducing clever shortcuts that only work until the system is under load, recovering from a crash, or serving concurrent requests.
For this sprint, every change had to satisfy a strict set of rules:
no public API changes
no storage format changes
no weakening of ACID behavior
no changes to RAFT boundaries
no speculative caching with unbounded memory growth
no benchmark-only tricks
no “fast, but only if nobody looks too closely” code
Every accepted change needed correctness tests, before-and-after benchmarks, and a full verification pass.
The biggest improvements came from query execution paths.
We improved those paths by making the query planner and execution code more careful about when it can stream from indices, when it can stop early, and when it can safely reuse already-decoded documents within a single query execution.
A few representative results from our internal benchmarks:
Sorted limited finder query
before: ~2.02 ms/op
after: ~0.035 ms/op
That is roughly a 58x improvement on that benchmarked path!
Full-scan filtered query
before: ~1.81 ms/op
after: ~1.44 ms/op
That is about 20% faster (and with fewer memory allocations).
Indexed range query
before: ~0.40 ms/op
after: ~0.33 ms/op
That is roughly 18% faster on the measured path.
We also tightened lower-level bounded index scans so that limits are honored earlier instead of scanning more data than needed and trimming later. That matters because “give me the first 20 matching results” should not behave internally like “find far more than 20 things and then throw most of them away”.
The engine layer also received careful improvements, mostly around iteration and read paths. These were deliberately conservative.
Where public APIs require stable byte slices, SyngoDB still returns stable byte slices. Where internal code can safely avoid extra value work and only needs keys, it now does so more efficiently.
That is the kind of performance work we like: measurable, boring in the right places, and not something that would turn into a future support ticket.
So what does this mean for Syncplify products?
It means the internal database layer behind them is now faster in several important areas, especially around searches, sorting, pagination, indexed lookups, metadata access, and internal scans.
It does not require customers to migrate anything. It does not require a configuration change. It does not alter the reliability model. It simply makes a core internal component better.
That is often the best kind of infrastructure improvement: not loud, not flashy, not something that requires a new checkbox in the UI, but something that improves the behavior of everything built on top of it.
SyngoDB remains the quiet database layer behind all Syncplify software. Now it is quieter, because it spends less time (less CPU, and less RAM) doing the same work.