SchemaPulse
PricingContact

Database operations & intelligence platform

Know every database.
Know what to do next.

The database operations and intelligence platform for MySQL, MongoDB, PostgreSQL and SQL Server — monitoring, incidents, backup and recovery, and provisioning, with an assistant that understands your environment.

Request a demoExplore the platform
schemapulse — fleet overviewexample data
Instances48
Open incidents2
Verified backups46
Recovery at risk1
Healthyorders-galera-0Galera · primary
Healthyorders-galera-1Galera · synced
Lag 4.2sbilling-rs-2Replica set · secondary
Healthyanalytics-pg-0PostgreSQL · primary
Unverifiedreporting-mssql-1SQL Server · standalone

The problem

Database operations are split across tools that do not talk to each other.

01

Signals scatter

Metrics in one tool, slow queries in another, topology in someone’s head. Answering “what happened” means four tabs and an hour.

02

Backups are hope, not proof

A green tick says the job finished. It does not say the data restores. Most teams find out during the incident.

03

Provisioning drifts

The database that gets built is not the database that gets monitored, and inventory stops matching reality within a quarter.

How it works

Monitor → Correlate → Recommend → Act

Four stages, one platform. Each stage feeds the next — which is what turns a metric into a decision.

  1. Stage 01

    Monitor

    See the whole estate — metrics, queries, topology and inventory, across every engine you run.

    • Monitoring & observability
    • Query analytics
    • Fleet & topology
  2. Stage 02

    Correlate

    Signals become incidents carrying context, instead of another wall of threshold alerts.

    • Incident correlation
    • Policy engine
    • Topology & election events
  3. Stage 03

    Recommend

    What needs attention, why it matters, and what to investigate first — with the evidence attached.

    • Recommendation engine
    • AI database assistant
    • Query intelligence
  4. Stage 04

    Act

    Close the loop — back up, restore to a point in time, provision, schedule maintenance.

    • Backup & recovery
    • Point-in-time recovery
    • Provisioning & automation

Intelligence · AI database assistant

It already knows your environment. Now you can just ask.

Not a chatbot with database knowledge. Your own estate — metrics, queries, topology, incidents, backups and inventory — with a way to interrogate it in plain language.

AI Database Assistantorders-galera · last 24h

What changed before this incident?

Three things changed in the 40 minutes before INC-2291 opened.

At 02:14 UTC orders-galera-1 lost and regained cluster membership, incrementing the Galera conf_id to 5. Write throughput shifted to galera-0, whose innodb_buffer_poolhit rate then fell from 99.2% to 94.1%.

At 02:31 a deployment added an index to orders.line_items. The query SELECT … WHERE order_id IN (…) changed plan and its mean latency rose from 8ms to 340ms.

The latency alert at 02:47 is most consistent with the plan change, not the membership event — the membership change resolved 12 minutes before latency began climbing.

Evidence

Electiongalera-1 · term 5 · 02:14:08Z
Metricbuffer_pool_hit_rate · 99.2% → 94.1%
Querydigest a3f19c · 8ms → 340ms mean
Deployschema change · 02:31:44Z
IncidentINC-2291 · opened 02:47:02Z

What the assistant reads

Metrics
Database and system metrics, per instance, at collection resolution
Queries
Slow queries, query timeline, index reports, plan history
Topology
Cluster shape, roles, elections, term snapshots, failovers
Incidents
Correlated incidents and their full event history
Backups
Runs, verifications, recovery points, restore history
Inventory
Hosts, versions, drift, provisioning and deployment history

Every answer cites the metric, query, event or run it drew on. An answer you cannot check is an answer you cannot act on.

How the assistant worksRoot-cause investigationThe Intelligence layer

Intelligence · recommendations

From showing information to explaining what requires attention.

Findings that carry their own evidence, impact and confidence — so you can judge them rather than trust them.

Backup policy has never produced a verified restore

reporting-mssql-1 · policy nightly-full-30d

Elevated
Finding
The policy has completed 94 consecutive runs. None has been followed by a successful verification, so the restore path has never been exercised.
Evidence
94 runs since 2026-06-02 · 0 verification records · last restore run never · storage target s3://backups-prod
Impact
One instance carrying 2.1 TB. Recovery time is unproven and the recoverable window is unconfirmed.
Action
Run a verification restore into an isolated target. SchemaPulse can schedule this in the existing maintenance window.
Confidence
High — derived from run records, not inference
Why now
Retention shortened to 30 days on 2026-08-28, reducing the recoverable window while verification remained absent.
Fig. 1This recommendation demonstrates insight that monitoring-only platforms typically cannot derive without backup-verification and recovery context.

See how recommendations are built

Platform · Monitoring & Alerting

See the whole estate. Know the moment it changes.

Database and host telemetry from a signed agent on every instance, across MySQL, MongoDB, PostgreSQL and SQL Server — and an alerting pipeline that turns what it finds into something a person can act on.

schemapulse — orders-galera-0 — database & system metricslast 6h · example data

Database metrics

Queries/sec4,812
Connections186
Buffer pool hit94.1%
Replica lag4.2s

Host metrics

HostCPUMemoryDiskTHP
orders-galera-062%71%44%Disabled
orders-galera-158%69%43%Disabled
billing-rs-281%88%76%Enabled

What you can monitor

Fleet health
Every instance across every engine on one screen, ordered by what needs attention rather than by name.
Database metrics
Engine-specific telemetry — throughput, connections, buffer and cache behaviour, locks, replication state.
Host metrics
CPU against core count, memory against total RAM, disk against capacity, connections and uptime — on the same timeline as the engine, because most "slow database" incidents are the host.
Host configuration
Transparent huge pages, swappiness, time sync, TCP keepalive, SELinux and firewall state per host. The settings that make a database slow while every graph looks fine.
Query behaviour
Slow queries, a query timeline you can line up against an incident, and index reports.
Replication & cluster
Replica lag, cluster membership, elections and term changes — kept as history, not just current state.
Topology awareness
Roles and state per engine: primary, replica, synced, arbiter, shard. Routers and mongos probed too.

What happens when something goes wrong

Alert rules
Thresholds per metric and per scope, so what matters on a write primary can be noise on a reporting replica.
Severity and state
Open, acknowledged, muted, resolved — each a recorded decision with an owner, not a gap.
Incident correlation
Related signals collapse into one incident carrying topology context and its full event history.
Maintenance windows
Planned work stops generating noise, so the alerts that do fire keep their meaning.
Notifications
PagerDuty, Jira, Slack, Microsoft Teams, webhooks and email — with acknowledge and resolve straight from the notification.
Alert history
Every firing, mute and acknowledgement retained, so a recurring problem is visible as a pattern.
schemapulse — alertsexample data
ActiveHistoryRules
SeverityRuleScopeAgeState
CriticalBackup verification missingreporting-mssql-12d 04hOpen
WarningReplica lag > 3sbilling-rs-200h 42mAcknowledged
WarningBuffer pool hit rate < 95%orders-galera-000h 18mOpen
InfoCluster membership changeorders-galera-112h 06mResolved
MutedDisk usage > 85%analytics-pg-0—Muted · maintenance

Incident · INC-2291 — correlated

02:14:08ZCluster membership change · orders-galera-1 · term 5
02:19:31ZBuffer pool hit rate fell below threshold · orders-galera-0
02:31:44ZSchema deployment recorded · orders.line_items
02:47:02ZLatency alert raised → correlated into INC-2291
02:47:04ZNotified · PagerDuty, Jira SP-418
03:02:55ZAcknowledged by on-call from notification link

Five raw signals, one incident, one page.

Explore MonitoringView Alerting & IncidentsSee Query Analytics

Platform · Deployment & Automation

SchemaPulse builds the database it then watches.

Most tools start once an instance already exists. The Deployment Manager provisions it — engine, topology, hosts, configuration and agent — so the database that gets created is the database that gets monitored, with no gap between the two.

schemapulse — deployment managerexample data
  1. 1EngineMySQL 8.4 LTS
  2. 2TopologyGalera · 3 nodes
  3. 3HostsGCP · nam-ne2 · n2-standard-8
  4. 4ConfigurationOS tuning · THP off
  5. 5Preflight9 checks passed
  6. 6Deployrunning

Preflight

PassSSH reachability
PassCredentials
PassTarget OS supported
PassDisk capacity
PassPorts available
PassTime sync

Progress

Done02_install
Done12_os_tuning
Running20_cluster
Queued30_agent
Queued40_register

On completion the nodes register into Inventory and monitoring begins — no separate onboarding step.

  1. 01

    Select

    Engine and version, then the topology — standalone, replication, Galera, InnoDB Cluster, replica set or sharded.

  2. 02

    Target

    Hosts from the cloud catalog, or existing machines you already run.

  3. 03

    Validate

    SSH reachability, credentials, capacity and ports checked before anything is created.

  4. 04

    Build

    Terraform for infrastructure, Ansible for configuration, with OS tuning applied before the engine first starts.

  5. 05

    Register

    Nodes enter Inventory and the agent is installed as part of the build.

  6. 06

    Operate

    Monitoring, alerting, backup policy and recommendations apply from the moment it exists.

Provisioning is not a fifth stage bolted onto Monitor → Correlate → Recommend → Act. It is what puts an instance into that loop in the first place, and what closes it when the answer is a new node.

Explore DeploymentView Fleet & TopologyRead Architecture

SchemaPulseDBChefs

Use SchemaPulse yourself — or run it with the experts who built it.

Deploy and operate SchemaPulse with your own database team, or combine the platform with DBChefs database engineers for implementation, optimisation, migrations, architecture and ongoing database operations.

Explore expert servicesTalk to us about SchemaPulse + DBChefs
  • Option 01

    SchemaPulse

    Licence the platform and run it with your own team. Basic, Operations, Intelligence.

    See pricing
  • Option 02

    DBChefs services

    Engage database specialists independently, with or without the platform.

    Explore services
  • Option 03

    SchemaPulse + DBChefs

    The platform, operated with expert support.

    Build a plan