Database engineering · EonTech

Data that stays
fast and correct.

We design schemas, tune queries, scale workloads, and run migrations without drama — across PostgreSQL and relational systems, with the right NoSQL store where it genuinely fits. Measured, reversible, and yours.

Start your project Data engineering
  • Senior engineers only
  • Measured, not guessed
  • GDPR · ISO 27001
Measured
Changes proven with before-and-after query plans
Reversible
Migrations ship with rollback paths and validation
Your data
Schemas, scripts, and infrastructure stay with you

Engineering practice

The discipline behind a database you can trust

Good database work is unglamorous and rigorous. We measure first, change carefully, and leave the system observable for the team that runs it.

  • Model for the queries. Schemas designed around how data is actually read and written, not just how it is drawn.
  • Index with intent. Indexes that match real query plans, reviewed against EXPLAIN, not guessed.
  • Migrations that are safe. Online, reversible schema changes that ship without a maintenance window.
  • Backups you have tested. Verified backups and rehearsed restores, because an untested backup is a hope.
  • Observability built in. Slow-query logs, metrics, and alerting so regressions surface before users feel them.
  • Least-privilege access. Scoped roles, encryption, and audit logging aligned to GDPR and ISO 27001.

What we do

Across the life of your data

  • Schema & data modelling

    Normalised where integrity matters, denormalised where reads demand it. We model for correctness first, then for speed.

  • Performance tuning

    Query analysis, indexing, and configuration work that turns slow, locking workloads into predictable ones — with the plans to prove it.

  • Scaling strategy

    Read replicas, partitioning, connection pooling, and caching introduced only when the data justifies them, not preemptively.

  • Migrations

    Version-to-version upgrades and engine moves executed with rollback paths, data validation, and zero-downtime techniques.

  • Relational depth

    Deep PostgreSQL and relational expertise — constraints, transactions, and the guarantees that keep your data honest.

  • NoSQL where it fits

    Document, key-value, and time-series stores chosen for the access pattern they suit, never as a default escape hatch.

The right store for the job

Relational by default, NoSQL by reason

A well-designed PostgreSQL database handles far more scale and complexity than most teams expect, and it gives you transactions, constraints, and ad-hoc querying that are costly to recreate elsewhere.

We reach for document, key-value, or time-series stores when the access pattern truly suits them — and we are honest when staying relational is the better, cheaper engineering decision.

See our data engineering work

How we work

Change a live database without fear

Production data leaves no room for guesswork. Every change is measured, reversible, and validated before it touches your users.

  1. 01

    Profile before touching

    We measure the real workload — slow queries, lock contention, growth — so changes target the actual bottleneck, not a suspected one.

  2. 02

    Design the change

    Schema, index, or topology changes are designed with a rollback path and validated against a copy of production-shaped data.

  3. 03

    Migrate without downtime

    Online migrations, backfills, and dual-write patterns where needed, so the change ships without a maintenance window or data loss.

  4. 04

    Verify and hand over

    We confirm the gains with measurements, leave observability in place, and document the model so your team owns it confidently.

Common questions

What teams ask about their database

  • Our database is slow — can you fix it?

    Usually, yes. We profile the real workload first — slow-query logs, query plans, lock contention, and growth — then fix the actual bottleneck through indexing, query rewrites, schema changes, or configuration. We show the before-and-after measurements rather than promising a headline number we cannot back.

  • Should we move off PostgreSQL to NoSQL?

    Often not. Relational databases handle far more scale than people assume, and they give you integrity and ad-hoc querying that are expensive to recreate. We move parts of a workload to a document, key-value, or time-series store only when the access pattern genuinely calls for it, and we are honest when staying relational is the better engineering choice.

  • Can you run a migration without downtime?

    In most cases, yes. We use online schema changes, backfills, and dual-write or replica-based cut-overs with validation and rollback paths, so version upgrades and engine moves happen without a maintenance window. Where a brief window is unavoidable, we tell you up front and keep it minimal.

Make your database boring again

Tell us where it hurts — slow queries, a looming migration, or a scaling wall. We will profile it and scope a fix you can measure.

Start your project Custom software