The database that drives itself
Every other database makes you its control loop. You size it for the worst hour you can imagine, tune it for a workload that changes the following week, and hold capacity in reserve against the burst that would otherwise take checkout down. A wall of knobs is a database admitting it does not know what it is running, and handing you the job.
Nobody babysits it.
ScramDB knows what it is running. The engine measures its own workload and moves its own limits as that workload moves: idle capacity goes to whatever is queued, transactions take priority the moment memory tightens, memory is handed back before the node runs out, and a change that turns out to hurt is taken back on its own. That is Ejder™, and it is part of the engine, not an advisor beside it: it does not email you a recommendation, it drives.
Why a database has to drive itself
Heavy analytics beside live transactions is a fight. One HTAP benchmark measured analytical work cutting transactional throughput by up to 89 percent (OLxPBench). A fixed limit cannot win it: set it low and analysts wait while memory sits idle, set it high and the next storm takes transactions down. It is a resource problem as much as an operational one: the setting that is safe under load is the one that leaves capacity unused for every hour that is not under load.
Automation has to be careful too. Across millions of cloud databases, about 11 percent of automated index changes had to be rolled back because they made things worse (Das et al., SIGMOD 2019). A database that tunes itself has to take its mistakes back.
What it is worth
The same node, the same demand, once with Ejder™ driving and once with it switched off.
| Outcome | With Ejder™ | Switched off |
|---|---|---|
| Reports served from the same queue | 985 | 400 |
| Transactions committed while memory is exhausted | 27,665 | 25,520 |
| Time spent shedding memory | 50 | 70 |
Reports that used to sit in a queue while memory went unused get run: 985 of 1,000 against 400, and the node never runs out of memory doing it. When memory is the thing under pressure, the priority flips and transactions win: 8.4 percent more of them commit through bursts that exhaust the node. Against a leak nothing can shed, it spends 29 percent less time shedding memory.
No operator set any of that, and none of it was revisited afterwards.
Reserved capacity is capacity that does no work
A limit set by hand has to be safe at the worst moment, which makes it wrong at every other one, and the difference is a machine standing idle while work waits beside it. In the first run above, the same node answered two and a half times the reports, with nothing added and nothing tuned.
A hand-set limit also decays. One that is conservative today grows more conservative as the workload builds around it; one that is aggressive stays aggressive until an incident corrects it. Ejder™ moves it continuously against what the node is actually doing, and releases memory before the node is exhausted rather than after.
Steady, not clever
An automation that panics is worse than none. Ejder™ changes little, and it holds: through hundreds of thousands of cycles of an endurance run it never once broke its own safety rules, and it never left a change in place that hurt.
What this is, and what it is not
The research figures are other teams' measurements of other systems, quoted from their papers.
Nothing to deploy for it, nothing to install, and switched off it consumes nothing: no thread, no counter, no schema.