Platform · Provisioning & Automation
Build the database. Then never onboard it.
Most platforms begin once an instance already exists, and onboarding it is your problem. SchemaPulse provisions the instance and registers it in the same run, so monitoring, alerting and backup policy apply from the moment it boots.
- 1EngineMySQL 8.4 LTS
- 2TopologyGalera · 3 nodes
- 3HostsGCP · nam-ne2 · n2-standard-8
- 4ConfigurationOS tuning · THP off
- 5Preflight9 checks passed
- 6Deployrunning
Preflight
Progress
On completion the nodes register into Inventory and monitoring begins — no separate onboarding step.
The workflow
Nine steps, in the order you meet them
- 01
Select the database technology
Engine and version, from the set SchemaPulse supports. The choice determines everything downstream — which backup engines apply, which topologies are offered, what tuning is appropriate.
- 02
Select the topology
Standalone, replication cluster, Galera, InnoDB Cluster, replica set or sharded cluster. Not a node count with a label attached — the topology drives node roles, quorum and the monitoring model that follows.
- 03
Define nodes and hosts
Provision new machines from the cloud catalog, or target hosts you already run. Sizing, region and disk are chosen here rather than discovered later.
- 04
Configure the deployment
Engine parameters, storage layout and OS tuning. Credentials come from the SSH key registry, which is keyed by environment and cluster type so staging keys cannot reach production hosts.
- 05
Validate prerequisites
A preflight catalogue runs before anything is created: SSH reachability, credentials, supported OS, disk capacity, port availability, time sync. A failed preflight costs a minute; a half-built cluster costs an afternoon.
- 06
Execute
Terraform provisions infrastructure, Ansible configures it. OS tuning — transparent huge pages, ulimits, sysctls — is applied before the engine first starts, so it boots correctly rather than being corrected afterwards.
- 07
Track progress
Per-role status as the run proceeds, with failures surfaced against the step that produced them instead of buried in a log.
- 08
Register the estate
Completed nodes enter Inventory with their versions, configuration and topology roles recorded. The agent is installed as part of the build.
- 09
Begin operations
Monitoring, alert rules, backup policy and recommendations apply from the moment the instance exists. There is no window in which a new database is running and invisible.
Coverage
What can be provisioned
- MySQL / MariaDBStandalone · Replication Cluster · Galera Cluster · InnoDB Cluster
- MongoDBStandalone · Replica Set · Sharded Cluster
- PostgreSQLStandalone · Streaming Replication · Logical Replication
- Microsoft SQL ServerStandalone · Always On Availability Groups · Failover Cluster Instances
Underneath
The automation, briefly
Terraform handles infrastructure and holds its own state; Ansible handles configuration through ordered roles. Both are driven from the control plane rather than from someone's laptop, which is the difference between a repeatable build and a build that worked once.
The ordering matters more than the tooling. OS tuning runs as a rolebefore installation, so transparent huge pages, ulimits and sysctls are correct the first time the engine starts — not applied afterwards to a process that has already made its allocation decisions.
That is as much implementation detail as this page should carry. If you want the full picture, the Architecturepage has the real deployment shape.
Why it matters
Where deployment connects back
Provisioning is what separates an operations platform from a monitoring dashboard. Every item below is configured by the build rather than by someone remembering to configure it afterwards.
- Fleet & Topology
- The topology chosen at step 2 is the topology SchemaPulse monitors — roles, quorum and election tracking are configured, not inferred.
- Monitoring
- The agent installed at step 8 begins reporting engine and host telemetry immediately.
- Backup & Recovery
- Backup engine capability is detected from what was actually installed, so policy options match the deployment.
- Incidents & Alerting
- Alert rules apply at the scope the new instance belongs to, without anyone remembering to add it.
- Inventory
- Versions and configuration are recorded at build time, which is what makes later drift detection meaningful.
- Intelligence
- Deployments are events on the same timeline as metrics and incidents — which is how "what changed before this" can answer with a schema change.