Software · Cloud and infrastructure

Database systems

Well-designed, fast and recoverable databases for the applications and reports your business depends on.

Slow pages and wrong reports often trace back to the database: missing indexes, tables designed in a hurry, or one server doing everything. We design schemas around how data is really used, tune the queries that matter, add replication, partitioning and connection pooling, and choose specialised stores like Redis or ClickHouse only where they earn their place.

What we build

Relational schemas with constraints that keep bad data out at the source
Query and index tuning based on real slow-query logs and execution plans
Read replicas, failover and connection pooling for busy applications
Partitioning and archiving for tables that grow by millions of rows
Online schema migrations that change live tables without long locks
Analytical stores in ClickHouse or DuckDB beside the operational database
Point-in-time recovery that is set up and rehearsed, not just configured

DemoInteractive · sample data

Try it live.

A working sample with made-up data. It runs in your browser; nothing is sent anywhere.

Tuning a slow querysample data

-- Before: 2.8 s, sequential scan on 41M rows
-- Fix: composite index matching filter and sort
CREATE INDEX CONCURRENTLY idx_orders_cust_created
  ON orders (customer_id, created_at DESC);

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, total, status, created_at
FROM orders
WHERE customer_id = 18342

What it does well

Plan-driven tuning

Changes are based on EXPLAIN ANALYZE output and measured before and after.

Integrity first

Foreign keys, checks and unique rules stop duplicates and orphans at the database.

High availability

Replicas with automatic failover through Patroni or a managed cloud database.

Safe migrations

Schema changes are versioned, reviewed and run in steps that do not block busy tables.

Right store per job

Redis for caching, ClickHouse for analytics, PostgreSQL for records, chosen by need.

Tested restores

Backups are restored on a schedule to prove they work and to time the recovery.

Questions

Our database is slow. Can you help without a rewrite?

Usually, yes. We read the slow-query log and execution plans, then add or fix indexes, rewrite the worst queries, tune memory and connection settings and add caching where it is safe. Most of the gain tends to come from a small number of queries.

SQL or NoSQL?

For most business data a relational database such as PostgreSQL is the right default: it handles JSON, full-text search and even vectors well. Document, key-value or wide-column stores fit specific patterns such as huge write volumes or loosely shaped event data. We decide by access pattern, not fashion.

Can you move us between database engines?

Yes, for example from SQL Server or Oracle to PostgreSQL. We convert the schema and stored code, migrate data with continuous replication, compare row counts and checksums, and test the application against the new engine before the cut-over.

Services that go with it

Data migrationYour records moved from old systems to new ones, cleaned on the way and reconciled before anyone switches over.Performance auditMeasured answers to why your software is slow, and a ranked list of the fixes that matter most.Software architectureA clear design for how your software is split, stores data, talks to other systems and grows, before code is written.

Related software

Data warehousesOne governed home for your business data, modelled so analysts and dashboards get the same answer every time.Storage softwareSoftware that stores, tiers and replicates your files and objects, so data stays available as it grows.Backup and recoveryEncrypted, off-site backups and rehearsed recovery plans that bring systems back after a failure or attack.Observability platformsMetrics, logs and traces in one place, with alerts that tell your team what broke and where to look.