Data
Data work covers design, tuning, migration and protection of relational and NoSQL databases. We build the schema and the backups, and a restore test is part of the job.
Our team designs, tunes, migrates and protects relational and NoSQL databases. We build the schema around how the business reads and writes data, set up replication and backups, and test restores on a schedule. Slow queries and unplanned downtime usually have a cause we can find and fix.
Data work often sits inside a larger build. The law firm platform and the weaving factory system on our track record page both began with a data model that fit how the people worked. We also review who can read what, so privacy duties are met in the design instead of by exception.
What we do
- Database design and indexing for performance
- PostgreSQL, MySQL and SQL Server administration
- Migrations between database engines
- Backup schedules with regular restore tests
- Disaster recovery plans with agreed recovery targets
- ETL pipelines between business systems
- Encryption of data at rest and in transit
- Query and slow-log tuning
- Immutable (WORM) backup copies so ransomware cannot delete restore points
- 3-2-1-1-0 design: three copies, two media, one offsite, one offline or immutable, zero restore errors
- Clean-room restore rehearsals on an isolated network before systems reconnect
Backups and disaster recovery are planned from recovery needs, not from what a tool can do by default. We help clients decide how much data they can afford to lose and how fast they must be running again, then build to that target. For ransomware, that means at least one copy that cannot be changed or deleted (immutable storage such as S3 Object Lock in compliance mode, or offline media), and restore tests into an isolated clean room before anything is reconnected.
Data work supports Tailored Software, Cloud Management and Cyber Automation. Applications we build rely on it, and the Super Intelligence practice depends on clean, well-organized data.
Leading platforms we work with
- PostgreSQL
- MySQL
- Microsoft SQL Server
- Redis
- MongoDB
- Oracle Database
- Snowflake
- Veeam
- Rubrik
- Commvault
Platforms and practices
- MariaDB
- SQLite
- SQL databases
- NoSQL databases
- restic
- Backups & disaster recovery
- Data migration & ETL
- Immutable backups and Object Lock
- 3-2-1-1-0 backup rule
- Clean-room restore
References
- Stack Overflow Developer Survey 2025: most-used databases
- Veeam: Leader, 2026 Gartner MQ for Data Protection; #1 IDC share 1H2026 (vendor page)
- Leaders in the 2025 Gartner Magic Quadrant for Backup and Data Protection Platforms: Rubrik, Veeam, Commvault, Cohesity, Dell, Druva (Virtualization Review, July 1, 2025)
- Amazon S3 Object Lock (WORM, governance and compliance modes, legal holds)
- CISA: #StopRansomware Guide (offline encrypted backups, restore testing, delete protection and object lock)
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
Backup tiers: data lost versus time to recover
Recovery point objective (RPO) is how much recent data a restore loses; recovery time objective (RTO) is how long the restore takes. Faster tiers sit close to the production system and share its fate; slower tiers survive ransomware and site loss. The scale is logarithmic. Illustrative figures.
Frequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhich databases do you support?
Our team works with PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle Database, MongoDB, Redis and SQLite.
How do you back up databases?
With tools such as restic and database-native methods, encrypted, with an offsite copy and regular restore tests.
What are RPO and RTO?
Recovery point objective is how much recent data you can afford to lose, measured in time. Recovery time objective is how long you can be down. A one-hour RPO means backups or replication at least hourly; a 15-minute RTO means a warm standby, not a restore from tape. The business states the numbers, then we build to them.
Can you migrate us from one database to another?
Yes, for example from Microsoft SQL Server or MySQL to PostgreSQL, or from a legacy system to a current one. We map the schema and data types, convert code that depends on engine features, migrate a copy first and compare results. A rehearsed cutover with a rollback plan keeps the production switch short.
How do you make a database fast?
Measure first: slow-query logs and execution plans show which queries cost the most. Then fix indexes, query shapes, schema issues and configuration, and only then hardware. Often one or two queries cause most of the load.
How do you test a backup?
By restoring it into a separate environment, starting the database, running consistency checks and comparing row counts or a known report against production. We time the restore to compare with the agreed recovery time. A backup that has never been restored is a hope and not a backup.