Operational Lifecycle Management

Keep every database current, without the downtime, or the runbooks.

Patching, version upgrades, compute and storage resize, and switchovers, scheduled into maintenance windows and sequenced automatically, so your estate stays current without manual coordination.

Talk to a Tessell engineerSee how a state agency cut patching downtime to under 1 min →

Trusted by enterprises at scale

US state environmental agency

Patching 30 min to under 1 min

Fortune 250 transportation company

10x faster lifecycle operations

Fortune 500 insurance company

85% of day-to-day operations automated

Keeping a database current is manual, risky, and invisible at scale.

Patching one database is a known procedure. Patching hundreds, on a schedule, without unplanned downtime or configuration drift, is where the operational cost lives.
Manual patching burns DBA hours, every cycle.

Manual patching burns DBA hours, every cycle.

Planning, change windows, rollback procedures, and validation repeat for every patch on every database. The effort scales with the estate, and the people who can do it safely are the same people you need for higher-value work.
High Availability patching is easy to get wrong.

High Availability patching is easy to get wrong.

The sequence matters. Patch the wrong node first, or switch over at the wrong moment, and a routine update becomes avoidable downtime on a database that was supposed to stay available through it.
There is no unified estate-wide view.

There is no unified estate-wide view.

What is scheduled, what ran, what failed, and which databases are behind on patches all live in separate places, if they are tracked at all. Patch compliance becomes a reporting exercise nobody owns.
What Tessell gives you

Current estate. One schedule. No manual runbooks.

Patching, upgrades, and resizes run as scheduled, automated, sequenced operations across every engine and every cloud. Here is what that looks like in practice.

/

Patching that does not mean an outage window.

Standby-First with rollover Multi-AZ switchover 60-120s (PostgreSQL, MySQL)Single-AZ 2-10 min Optional second switchover to restore roles Pre-patch snapshot prompted

For HA databases, Tessell patches with a Standby-First approach and rollover. The standby is patched first while the primary keeps serving traffic, a controlled switchover moves traffic to the patched node, then the original primary is patched. Downtime is limited to the switchover itself, and an optional second switchover restores the original primary and standby roles. A pre-patch snapshot is prompted before the operation begins.

US state environmental agency
Patching downtime cut from 30 minutes to under 1 minute, through rolling clustered patching across a consolidated Oracle estate.
/

The whole estate, on one schedule

Weekly, monthly, or quarterly windows 30-minute incrementsStatus: Success, In Progress, Queued, Failed, Aborted Downtime and duration shown per activity · Reschedule, Start Now, or Cancel Scheduled-by Tessell or user

Each database has a maintenance window you set by day, time, and duration. OS patches, engine version upgrades, parameter profile updates, compute and storage resizes, and switchovers queue to run inside it, not the moment they are requested. Every activity shows its status and whether it causes downtime, and you can reschedule it, start it now, or cancel it before it runs.

Fortune 500 insurance company
85% of day-to-day database operations automated across a 33 data center migration, with zero application refactoring.
/

Stay current with every engine release.

Oracle PSUs within 2 weeks of release One-off patches supportedAuto minor version upgrades Backward-compatible PostgreSQL and MySQL minor upgrades Oracle, SQL Server, PostgreSQL, MySQL

New Oracle PSUs are available on the platform within two weeks of Oracle's release, so your estate stays current without manual tracking. One-off patches are supported when you need a specific fix, and minor version upgrades can apply automatically inside the maintenance window you already set. PostgreSQL and MySQL minor upgrades are backward-compatible and applied through the same rolling approach.

Fortune 250 transportation company
10x faster database lifecycle operations across 500+ Oracle databases.
Governance and Control

Policy Enforcement is strongest when the estate behind it is fully protected and fully visible

Consistent governance is one part of a larger architecture. Tessell's Governance and Control brings all three together.

Security and Compliance

The architecture that ensures every governed database stays within your perimeter

Your data runs inside your own cloud account, under your keys, on your network so governance and sovereignty work together rather than as separate decisions.

Explore Security and Compliance
Cost Visibility

A complete cost picture of the estate your policies govern

Per-database cost attribution across compute, storage, licensing, and backup so the estate you've governed is also the estate you can fully optimize.

Explore Cost Visibility
Get started

See your patching and lifecycle operations in your own environment.

Walk through the maintenance window, the Standby-First patch flow, and estate-wide scheduling with a Tessell engineer, using your engines, your cloud, and your change-management requirements

Talk to a Tessell engineerRequest a maintenance walkthrough →
Frequently Asked
Questions
For HA databases, Tessell uses a Standby-First approach with rollover. The standby is patched first while the primary keeps serving traffic. A controlled switchover then moves traffic to the patched node, and the original primary is patched afterward. Downtime is limited to the switchover itself. An optional second switchover restores the original primary and standby roles once both nodes are current.
For PostgreSQL and MySQL on Multi-AZ, the switchover during a rolling upgrade typically completes in 60 to 120 seconds. For single-AZ PostgreSQL, where the service stops, patches, and restarts, downtime is typically 2 to 10 minutes. Oracle and SQL Server HA services use the Standby-First rollover approach, and SQL Server displays an estimated downtime before the patch starts. Exact timing depends on transaction state at switchover.
Oracle Patch Set Updates are made available on the platform within two weeks of Oracle's release, so your estate can stay current without tracking releases manually. You apply them inside your maintenance window like any other scheduled activity.
Yes. Alongside scheduled PSU and minor version updates, Tessell supports one-off patches when you need a specific fix applied outside the standard cadence.
Yes. Every scheduled activity in the maintenance window can be rescheduled to a new date and time, started immediately with Start Now, or cancelled before it runs.
OS patching and updates, database engine minor version upgrades (when auto minor version upgrade is enabled), parameter profile updates, compute resize, storage and IOPS resize, and switchover and switchback operations. Activities queue to execute within the window rather than the moment they are requested.
Compute resize is available post-provisioning for Standard shapes; High Performance shapes are set at provisioning and are not resized afterward. For HA services, resize uses the same rollover approach used for patching to minimize downtime, with the primary and HA instance modified together.
The Maintenance Window tab retains a record of scheduled and completed activities, each with its status (Success, In Progress, Queued, Failed, Aborted), its impact and estimated duration, and whether it was scheduled by Tessell or by a user. This gives security and compliance teams a continuous record of what was patched and when, supporting your patch-compliance requirements without assembling evidence across systems.