Skip to content

Database Administration

The database is the component that forgives improvisation the least. A stateless application recovers with a rollout restart; a database that was badly installed, badly replicated or never restore-tested turns into permanent loss.

InteSys runs databases as a managed service: installation, migration, day-to-day administration, tuning, replication, backup and a disaster recovery plan — on Kubernetes or on virtual machines, in the br-sp-1 (Cirion SAO1) and br-sp-2 (Equinix SP3) regions, with all data kept in Brazil.

Database lifecycle: install, migrate, operate, optimize and protect, looping back to measurement

Every stage of the cycle has its own guide in this section; the last one feeds back into the first.


Engines we run

Engine Workload profile Guides
MySQL / MariaDB Transactional OLTP, the most common choice in web applications High availability · Multi-region
PostgreSQL OLTP with strong integrity requirements, extensions and advanced SQL High availability · Multi-region
ClickHouse Columnar analytics, aggregations over billions of rows High availability
CockroachDB Distributed, local writes in several regions Multi-region
Valkey / Redis In-memory cache and queue, supporting the main database On request

The lifecycle, guide by guide

Installation

Sizing, topology choice, provisioning through Infrastructure as Code, hardening, and validation with a load test and a failure test before production traffic arrives.

Migration

Moving off a self-hosted server, a foreign provider or a public cloud managed database, with an initial load, change replication and a cutover window measured in seconds.

Administration

Day-2 operations: users and privileges, version upgrades, schema changes that don't lock the table, capacity management, on-call and runbooks.

Performance Tuning

A diagnostic method, execution plan reading, indexes, memory, connection pooling and I/O — in the order in which each layer actually costs milliseconds.

Replication

Physical and logical replication, synchronous and asynchronous modes, cascading topologies, lag monitoring, and what each arrangement buys you in RPO.

Backup & Restore

Full backups, incrementals, encrypted volume snapshots and a continuous log archive for point-in-time recovery — with restores tested on a schedule, not during the incident.

Disaster Recovery

Agreed RPO and RTO, covered scenarios, the failover procedure between br-sp-1 and br-sp-2, failback, and periodic drills.


What's included

  • Declarative provisioning — topology, version and backup policy in a versioned manifest, not in a manual step.
  • High availability by default — an odd number of voting members, anti-affinity, and fencing before any promotion.
  • Backups with tested restores — a backup that has never been restored is an assumption.
  • Observability wired to on-call — metrics, dashboards and alerts, with a runbook behind every alert.
  • Data sovereignty — primary data, replicas, logs and backups stay in Brazil; data leaves the country only when the customer asks.
  • Handover documentation — the customer receives topology, credentials, runbook and DR plan in writing.

We don't replace your team — we cover the shift it can't

Many customers have a strong development team and no DBA on call. The most common arrangement is InteSys owning the architecture, the on-call rotation and the critical procedures, while the customer's team stays the owner of the schema and the queries.


Engagement models

Model Description Best for
Project Fixed scope: install, migrate or restructure a cluster Leaving a provider, launching a product, fixing an architecture
Managed operations Continuous operation with on-call and an SLA Critical production without an in-house DBA
Point consulting Performance diagnosis, architecture or DR plan review An internal team that needs a second opinion

Next Steps