Takeover, checked.
Can the standby host carry the primary's CPU, memory and IOPS once the databases that may stop have stopped — with the replica inside its RPO? Fits, fits after stopping, does not fit — or unknown when the evidence is old.
Managed database hosting
Every standby, ready.Every processor, licensed.
For managed database providers and their teams — operations, licences, customer management and capacity: Rymvard checks whether every standby could carry production today, sets the processors your licence rules require against what you own, and finds the next database a host with a standby partner.
Read-only. New in version 0.26 — the screens show an illustrative example estate, not a customer.
A standby nobody has tried.
Replication looks healthy until the day of the takeover — and the standby host turns out to be full of test databases, or hours behind. And the licence audit asks for processors and options nobody counted.
Licences you can defend.
Processors needed per product — physical cores times the core factor, the cluster rule, standbys and options in use — from the entitlements and rules you enter. Rymvard counts; your contract decides.
Room for the next one.
A new database gets the best-fitting host and a standby partner at another site, preferring hosts that are already licensed.
What Rymvard shows
One view of every database estate.
Instances, replication groups and licence positions — each figure traceable to the record and the moment it was observed.
Replication groups.
Oracle Data Guard and SQL Server availability groups as one model — primary, standbys, lag and RPO — with the takeover check for every group.
Options in use.
Options and packs in use without an entitlement are named before an auditor names them. Where a rule is missing, the position is unknown, not zero.
The S/4HANA bridge.
When SAP systems move to HANA, the database processors they free return to the licence pool — quarter by quarter, once their retirement is confirmed.
Customers kept apart.
Each customer's instances, their protection and the versions leaving support within 24 months — customer names only for the people who need them.
Read-only, from your database estate.
Rymvard reads what your inventory and monitoring already know. It never connects to change a database.
- Instances, databases, hosts and replication groups through a vendor-neutral ingest API or CSV templates.
- Core factors, licence rules and entitlements exactly as you enter them — Rymvard does not interpret a contract.
- Replication lag older than one hour makes a takeover unknown — never a green tick.
- Detailed records stay in their country; customer names are visible only to the people who need them.
New in 0.26 · Workspaces
Four homes for database teams.
Database operations, licensing, customer management and capacity planning each open Rymvard on their own home — their question, their four figures and only the findings that concern them, with AI that explains every number and suggests the next step. See the workspaces
Database Operations
Can every standby carry production today?
- Database takeovers that would fail
- Database takeovers unknown
- Database standbys behind RPO
- PRD databases without a standby
Database Licences & Audit
Is every processor licensed and every option accounted for?
- Database processors needed
- Database processors entitled
- Database products short
- Database options without entitlement
Database Customer Management
Is every customer's database estate protected and current?
- Database customers with unprotected PRD
- Database customers with failing takeover
- Database versions leaving support within 24 months
- Database customers
Database Capacity & Placement
Where does the next database go — with its standby?
- L databases that fit with a standby partner
- Licensed database processor headroom
- Database processors freed by S/4, next 4 quarters
- Database sites with unknown IOPS
Screens from the running product on its example estate. Customer names appear only for planners and admins — findings never name a customer.
Across every solution
Recovery, together.
When a site fails, workloads from every solution land on the same recovery destination. Rymvard checks them together and sets each recovery time against the restore throughput your tests measured. Joint recovery
Check every takeover before you need it.
One database estate, read-only: which standbys hold, which processors are short, where the next database fits.