Skip to content
Balkan Tecnologia
AccessibilityGet in touch
Balkan Tecnologia

A database designed for the load it really gets

We design the data model, add the right indexes and rewrite slow queries based on what the system really does, measuring before and after.

A mint-green thread wound on three wooden bobbins, running from one to the next.

Who it's for

For companies whose system has slowed down as data has grown, or that are starting a product from scratch.

What it solves

  • Screens and reports that used to open instantly now drag, and nobody knows which query is to blame.
  • Tables grew without a plan, and the same data turns up in different places.
  • Changing a column in production is nerve-racking, because there is no history of database changes.
  • The CNPJ is stored as a number, and new CNPJs, which include letters, do not fit.
  • Every traffic peak ends with the database at its limit and the system slow for everyone.

What we do

Data model
Tables, relationships and constraints designed from the business rules, not from each screen.
Finding the slow queries
We measure which queries use the most time and resources, and start with those.
Indexes and rewritten queries
Indexes built for the real queries and queries rewritten, with the gain measured at every change.
Versioned schema migrations
Every database change becomes a reviewed, tested script, applied the same way in every environment.
Brazilian fields
CPF, the alphanumeric CNPJ, CEP and amounts in reais, typed and validated from the start.
Cache and read replicas
When the measurements justify it, frequent reads move off the main database to a cache or a replica.

What you get

  • A documented data model, with a diagram and a field dictionary
  • A slow-query report, with before-and-after measurements
  • Tuned indexes and queries, in production
  • Versioned schema migrations in your repository
  • A database performance dashboard, with an alert when a query gets worse

How we do it

  1. Measurement

    We collect the real queries, the data volumes and the peak hours.

  2. Diagnosis

    We pin down the bottleneck: the model, indexes, queries or database settings.

  3. Changes in staging

    Each change is tested with a data volume close to production's.

  4. Release

    Changes applied through versioned migrations, at an agreed time and with a way back.

  5. Follow-up

    We compare new measurements with the starting point and adjust whatever still drags.

Technology examples

  • PostgreSQL
  • MySQL
  • SQL Server
  • Redis
  • Flyway
  • pg_stat_statements

Related services

FAQ

Do we need to switch databases?

Usually that is not the first step. Tuning the model, indexes and queries in the current database tends to cost less; switching comes up only if measurements show a limit it cannot handle, and then it becomes a data migration.

SQL or NoSQL?

It depends on the shape of the data and how it is queried. For orders, payments and customer records, with relationships and transactions, a relational database usually fits; another kind comes in when there is a measured reason.

Can the changes be made without taking the system down?

Many changes, such as creating indexes, can be made with the system running. Those that need a maintenance window are agreed in advance, with a time and a way back.

What if the problem is in the code, not the database?

It happens: a screen that runs the same query many times over, for example. In that case we fix the code that talks to the database or point your team to the exact spot.

Write to Balkan

Talk to us about your project