Database services
The part of your system that is hardest to fix later.
Most problems that look like software problems are data problems underneath: the report that takes an hour, the two systems that disagree about a customer, the record that exists three times. We design how your information is stored, move it safely, and prove the backups work.
CactusCode's financial system came across with every historical record intact.
Overview
Database, the way we do it
A database is the one part of a system you cannot casually redo. Code gets rewritten every few years; the data outlives it, and every decision made early about how it is shaped is one you live with. That is why we start there rather than arriving at it after the screens are drawn.
We design schemas that stay quick as the business grows, move data off whatever it lives in today without losing a record, and back it up daily. Unlike most backups, ours are tested: we restore from them on a schedule to prove they work rather than assuming it.
What's included
What you actually get
- Designed so it stays fast as the volume grows
- Migrated from the old system in stages, with the counts reconciled afterwards
- Backed up daily, and the restore actually tested
- Slow queries traced to the cause and fixed, not masked with more hardware
- Access locked to named accounts with the minimum each person needs
How we work
Five steps, no surprises
- 01
We talk
A call or a WhatsApp thread. You tell us what is not working; we tell you honestly whether we are the right people.
- 02
We scope it
A written plan with what you get, what it costs and how long it takes. Fixed, so there are no surprises later.
- 03
We build it
You see it as it goes, not at the end. Changes are cheap while it is still being built.
- 04
We put it live
On infrastructure we set up and secure, tested before the launch date.
- 05
We keep it running
Updates, monitoring and someone who answers. Most clients stay on a monthly agreement.
Questions
About database
Will we lose anything in a migration?
No. We keep a full copy of the original before starting and reconcile the counts afterwards. If one record does not match we find out why before going further, and the old system stays live until you are satisfied.
Which database should we use?
Usually PostgreSQL or MySQL, because they are proven, well understood and easy to hire for. We reach for MongoDB when the shape of the data genuinely warrants it, not because it is newer.
How often is it backed up?
Daily by default, more often where the business needs it, and we restore from those backups on a schedule so you know they work.
Also
Related work
- Quality AssuranceFind it before your customers do.
- UX DesignWork out what it should do before anyone builds it.
- UI DesignScreens people can use without being trained.
- Design SystemsOne set of rules, so the tenth screen looks like the first.
- Mobile ApplicationsApps people keep on the first screen.
- iOSiPhone apps built the way Apple expects.
- AndroidAndroid apps that work on the phones people actually own.
- FlutterFlutter, when one team has to cover both stores.
- AIAI that does one job, properly.
- Machine LearningModels that earn their place in the business.
- Data ScienceAnswers from the data you already have.
- LLMsLanguage models, kept on a short leash.
- Generative AIGeneration with a human still holding the pen.
- PythonPython, for the work that has to be read as well as run.
- Back-EndWhere an order becomes an order.
- Node.jsNode.js, for the systems that have to answer quickly.
- GoGo, where it has to be fast and stay simple.
- .NET.NET, for the systems a business runs on.
- JavaJava, for systems measured in decades.
- Front-EndThe half of your product people actually see.
- Web DevelopmentCompany sites, customer portals, and web systems that hold up.
- ReactReact, built so the next team can still work on it.
- AngularAngular, for systems that have to last.
Tell us what you have in mind.
An engineer reads your message and replies to you directly.
Talk to us