SQL Server & Azure SQL
The platform this firm was built on. On-premises instances, Azure SQL Database and Managed Instance, availability groups and clusters, the BI stack, and the licensing position underneath all of it.
Platform Coverage
Database platforms we support
Most estates run more than one database engine. Most partners staff for one. Fortified Data runs all four, so a mixed environment gets one team, one set of findings, and one number to call rather than four.
Senior US-based DBAs on every platform.
What Fortified Data does on each platform
Fortified Data runs, tunes, secures, and migrates Microsoft SQL Server and Azure SQL, Oracle, PostgreSQL, and MySQL, on premises and in AWS, Microsoft Azure, and Google Cloud. Each platform page states the work performed on that engine, the versions and configurations supported, and what a client receives, across managed services, fixed-scope consulting projects, and assessments.
The four pages below are deliberately narrow. Somebody researching an Oracle partner does not need Oracle explained to them. They need to know which configurations a team has actually run, whether it has been through a licensing audit, and what happens at two in the morning.
What follows the four cards is what holds true whichever engine you run. The differences are on the pages themselves.
What every platform engagement carries
The commands differ by engine. The obligations do not.
- Monitoring and incident responseContinuous health checks across performance, availability, and security, with alerting and remediation attached rather than a notification nobody owns.
- Performance tuningQuery, index, and server configuration work, run as ongoing maintenance rather than as an emergency response to a complaint.
- Patching and maintenanceScheduled and emergency patching, planned around your maintenance windows, so the environment stays supported and compliant.
- Backup and recovery oversightStrategy design, verification that the backups completed, and recovery testing that establishes they restore.
- High availability and disaster recoveryArchitecture, failover configuration, and replication designed against your recovery time and recovery point objectives rather than against a product default.
- Capacity planning and reportingGrowth forecasting and regular written reporting on system health, so the next constraint is visible before it becomes an outage.
The four platforms
Each page states what Fortified Data does on that engine, which versions and configurations are supported, and what arrives at the end of an engagement.
Oracle
RAC, Data Guard, ASM, Exadata, and GoldenGate, run by DBAs who have been through an Oracle licensing audit and know what gets asked for.
PostgreSQL
Managed and self-hosted PostgreSQL, replication and failover, extension and advanced feature work, and the migration route off a commercial engine.
MySQL
Replication topologies, read replicas, sharding and partitioning, and the scaling work a high-transaction MySQL estate needs before it hits the wall.
Why it matters who holds the estate
One team across four platforms
A mixed estate gets one opinion
Four platform specialists produce four reports, four views of where the problem is, and no picture of the system the business actually runs. One team that covers all four produces one.
The route between engines is the work
Consolidation, licensing pressure, and modernization all end in a move from one platform to another. That project needs a team fluent on both sides of it, not a specialist on either.
Managed, project, or both
Every platform here is available as an ongoing managed service, as a fixed-scope consulting engagement, or as an assessment that establishes which of the two you need.
Between platforms
The work that crosses engines
Consolidation, a licensing renewal, or a modernization program all arrive at the same place: something has to move from one platform to another. These are the routes Fortified Data runs, and each is a fixed-scope engagement rather than an open-ended project.
Oracle to PostgreSQL
The move driven by licensing cost more often than by technology. Schema and PL/SQL conversion, application compatibility, and a performance comparison against the Oracle baseline, so the saving is measured rather than assumed. Run as a migration engagement.
Oracle to SQL Server
Heterogeneous migration with full application compatibility, including the stored procedure and data type conversion that decides whether the target behaves the way the source did.
SQL Server to Azure SQL
Azure SQL Database, Managed Instance, or SQL Server on an Azure virtual machine, chosen on compatibility and cost rather than on the default. The SQL Server page covers how that choice gets made.
Commercial to open source
Oracle or SQL Server workloads moved to PostgreSQL or MySQL where the workload suits it. The assessment also names the workloads that do not, which is the half of this decision most business cases skip.
Version upgrades in place
Moving off an end-of-life version without changing engine. The same phases, a shorter compatibility list, and the same requirement for a tested way back before anything changes.
Consolidation across engines
Instance sprawl reduced and workloads consolidated, which lowers licensing and management cost on every platform here. Usually scoped from a health check rather than from a wish list.
Common questions about platform coverage
Which database platforms does Fortified Data support?
Microsoft SQL Server and Azure SQL, Oracle, PostgreSQL, and MySQL. Each is supported on premises, in AWS, Microsoft Azure, or Google Cloud, or in a hybrid arrangement across both, and each is available for managed services, consulting projects, and assessments.
Can one team cover an estate running more than one database platform?
Yes, and that is the usual case rather than the exception. Fortified Data assesses, reports on, and manages a mixed estate as one environment, with one set of findings and one team, rather than splitting it into a separate engagement per engine.
Does Fortified Data support MariaDB?
Yes. MariaDB environments are supported alongside MySQL, covering configuration, performance, security, replication, and upgrade work. The Fortified Data MySQL page describes the operational model that applies to both.
Do you support cloud managed database services as well as self-hosted instances?
Yes. Fortified Data supports Amazon RDS, Google Cloud SQL, and Azure Database alongside self-hosted instances, and supports the Azure SQL family for SQL Server workloads. A managed cloud service removes some of the administrative work and none of the performance, security, cost, or design work, which is the part clients typically bring us.
Can Fortified Data migrate a database from one platform to another?
Yes. Cross-platform migrations, such as Oracle to PostgreSQL or Oracle to SQL Server, are run as fixed-scope engagements with compatibility analysis, schema and code conversion, row-level validation, and a tested rollback path at every phase.
Do you support database versions that are past their vendor support date?
Yes. Fortified Data supports legacy versions across all four platforms and treats an unsupported version as a risk to be planned down rather than a reason to decline the work. A version past its support date receives no security patches, so the engagement normally combines stabilizing what is running now with a costed upgrade or migration path off it.
Tell us what you run
One conversation covers the whole estate, whichever engines are in it. If you would rather start with evidence than with a meeting, a health check assesses every platform you run in a single engagement and reports them in a single document.
Let us show you what's possible.
Two ways to start
One team across SQL Server, Oracle, PostgreSQL, and MySQL.