Managed Database Services in Kenya
CloudSpinx runs production databases for businesses in Kenya and across East Africa: PostgreSQL, MongoDB, MySQL, MariaDB and Valkey, with replication that fails over, point-in-time recovery somebody has actually restored from, and an encryption story you can explain to an auditor. We also do the unglamorous half of database administration, which is reading your slow queries, your index bloat and your log growth before any of the three become an incident. No hyperscaler runs a database region in Kenya, so if residency is what brought you here, the architecture is the entire conversation and we would rather have it before you sign anything. Cost follows the engine, the data volume, how far back you need to restore and how much of the running we take, which is why we scope every engagement instead of publishing tiers.
Who we build for
- 14organizations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our Managed Databases Service
Every engagement covers the full scope: no hidden extras, no upselling.
Managed PostgreSQL
PostgreSQL on the major version your application vendor actually supports, with streaming replication, Patroni for automatic promotion, pgBackRest for the backup chain, pgBouncer once connection counts justify it, and pg_stat_statements enabled from the first day, because you cannot fix a slow query nothing recorded.
Managed MongoDB replica sets
A three-member replica set with a real majority, write concern and read preference set deliberately rather than left at the default, oplog sized against your measured write rate, and an election rehearsed in front of you before anything goes live.
Managed MySQL and MariaDB
MySQL or MariaDB with asynchronous replicas, or Galera where the write pattern genuinely suits it, Percona XtraBackup for hot copies, and binary logs archived so that your recovery point is a decision somebody made rather than whatever the last dump happened to catch.
Managed Valkey and Redis
Cache, sessions and job queues, with persistence chosen on purpose: a cache that may be lost on restart, or a queue that may not. Two different configurations, and the wrong one drops background jobs quietly for weeks before anybody notices.
MongoDB Atlas migration
Moving off a foreign managed service without a surprise. We inventory what the platform gave you that plain MongoDB does not, prove the restore in a rehearsal with the timings written down, then run the cutover in a window you pick, with a rollback point.
Database residency in Kenya
The database placed in Kenya where that is genuinely the requirement, with the instrument that requires it named in writing. We also tell you when moving the database alone changes nothing, because the application processing the data is still sitting somewhere else.
Encryption at rest and in transit
AES-256 at rest through the volume or the engine, TLS between the application and the database and between the nodes, keys held away from the data in Vault or a KMIP provider, and a plain account of which attack each layer stops.
Backup, point-in-time recovery and restore tests
A base copy plus a continuous log archive, retention on object storage under a lock nobody can shorten, and a restore run every month into a throwaway instance. A backup nobody has restored from is a hypothesis, not a control.
High availability and failover drills
Automatic failover where a majority exists, a written promotion path where it does not, and a drill on the calendar. We take a node down on purpose in a window you choose, then hand you the measured timings rather than a vendor number.
Slow query and index review
The reason the application got slow is almost never the hardware. pg_stat_statements, the MongoDB slow query log and an index review find it, and the answer is usually one missing index, one query pulling the whole table, or a connection pool nobody sized.
Monitoring and 24/7 response
Replication lag, disk headroom, connection saturation, oplog and write-ahead log growth, plus the checks that catch a backup that failed rather than a disk that filled. Alerts reach an engineer, with a 1-hour response on a P1.
Major version upgrades
Upgrades planned against the vendor support window rather than against panic, rehearsed on a copy of your data, and cut over with logical replication where downtime is expensive. A release past end of life stops getting security fixes, and on most estates nobody owns that calendar.
Technologies we use
What a database we would agree to run looks like
Three drawings from the design phase of a database engagement: the shape that survives losing a node, the failure that replication makes worse rather than better, and what the word encrypted covers once you read the vendor documentation. Node counts and sizing come out of your own metrics, never out of a template.
A three-node replica set with no public database address
Two things in this drawing do most of the work. The database nodes hold no public address at all, so the only route to your data runs through an application the firewall knows about. And there are three of them, because a majority of three is two: lose one node and an election promotes a replacement while writes carry on. Patroni over an etcd majority does the same job for PostgreSQL that the replica set protocol does for MongoDB.
- application and replication traffic
- backup and log archive
Why a replica does not save you from a bad write
Replication is a correctness machine. It applies what the primary did, faithfully, including the update with a missing WHERE clause and the migration that ran against the wrong environment. On a local link that copy arrives inside the replication interval, which is milliseconds, and now the mistake exists three times. The only thing that gets you back is a base copy plus the log archive, replayed to a moment you choose. That is a different control, priced separately, and it is the one we test monthly.
What database encryption at rest actually defends
This is the figure that costs us upsells, so read it before signing anything with the word encrypted in it. Volume and engine encryption defend a disk that leaves the building. They do nothing about a credential in a repository, because the application is entitled to read the data and the storage layer cannot tell a thief holding a valid password from a customer. The controls in the right column are the ones that answer that, and they are cheaper than the ones on the left.
Which shape do you actually need?
Most enquiries arrive asking for the third one. Plenty of them should buy the second, and a few should buy the first and spend the difference on backups they have restored from. We say which on the first call.
A single managed instance
One database, monitored, patched, backed up, with restores tested on a calendar. A restart is visible to users and a host failure is a restore rather than a failover.
Right when an hour of downtime is survivable and the data matters more than the uptime.
Primary plus a standby
A second copy kept current, promoted by a human following a runbook. It removes the restore from your recovery path and does not remove the phone call.
Right when you want a fast recovery and can accept that somebody has to decide.
A replica set with automatic failover
The shape in figure 01. A majority exists, so a node loss is an election rather than an incident, and maintenance stops needing a window.
Right when writes cannot pause for a person to wake up and read a runbook.
We run it where it already is
Your managed service in your own account, run properly: parameter groups, replication, PITR windows, slow queries, upgrades and cost. No migration, no lock-in to us.
Right when the platform is fine and the operating discipline is what is missing.
Nothing above is a quote for a specific number of nodes. Sizing comes from your own working set, write rate and log growth, which we read from your existing metrics before proposing anything. A vendor who sizes a database from a feature list has told you how the engagement will go.
What managed database services cost in Kenya
Two engagements with the same engine and the same data size can differ by a factor of four, and the difference is almost never the software. It is how fast you need to be back, how far back you need to go, and whether a human being has to be awake for a failover. So we scope rather than publish tiers. Send us the engine, the data volume and the recovery window through the form below and you get one figure with the reasoning attached. Where the nodes physically sit is a separate decision we are happy to make with you, whether that is hardware we run for you or an account you already own.
- The engine and its license position: PostgreSQL, MariaDB and Valkey cost nothing to license, MongoDB Community costs nothing to run, and the one feature people assume is free is the one that is not (see the encryption section below)
- Working set, not disk size: what has to stay in memory sets the node, and MongoDB sizes its cache at half of RAM minus a gigabyte by default, so a 4 GB node holds a 1.5 GB cache whatever the disk says
- Node count and whether failover is automatic: one node, a standby somebody promotes, or a three-member set that promotes itself. The third costs the most and wakes nobody up
- How far back you can restore: a nightly copy is cheap, and a 35-day point-in-time recovery window is priced by the log archive it has to keep, which grows with your write rate rather than your data size
- Read replicas and reporting: analysts running heavy queries against the primary is the most common cause of a slow application in this market, and a read replica is usually cheaper than a bigger primary
- Migration scope: a rehearsed cutover off a managed platform is fixed-fee work, and the price is set by what the old platform did that the new one has to be taught to do
- Who holds the platform: we can run your database in your own cloud account, in infrastructure we design with you, or on machines we operate. All three are normal and only one of them is a lock-in
- Hours of cover: business hours, extended weekdays or 24/7. Choose this honestly, because paying for nights you do not need is the easiest line to cut and the worst one to discover you cut
Managed MongoDB in Kenya, and leaving MongoDB Atlas
The enquiry usually arrives the same way. A platform is on a managed MongoDB service in a region outside the country, somebody has read the Data Protection Act, and the data has to come home. The database part of that is straightforward and we have done it. The part that catches projects is everything the managed platform quietly did for you, because none of it exists in plain MongoDB and each piece needs a decision before the cutover date is set rather than after.
What the migration tooling will and will not do
MongoDB publishes the constraints, so there is no need to guess. The mongosync limitations page states plainly that it supports WiredTiger clusters only, that a shared tier is not supported and neither are serverless clusters, and that it does not sync Atlas Search indexes. It also refuses a major or minor version change during a migration. So a shared-tier cluster is a dump and restore with a planned window, and a dedicated cluster can be live-synced and cut over in minutes. Which one you are decides the whole shape of the plan, and it is the first thing we check.
The features that do not come with you
Atlas Search is the one that reprices a project. It is a platform service, not a MongoDB feature, so leaving means either native text indexes if the queries are simple enough, or a dedicated search service beside the database. Triggers, the Data API and Charts are the same class of problem. We inventory these first and quote the replacement separately, because finding one of them a week before cutover is how a migration turns into a rebuild. There is no Atlas region in Kenya or anywhere in East Africa either, which is the whole reason this conversation exists: the published AWS region list reaches Cape Town and stops.
MongoDB encryption at rest without an Enterprise license
This is the single most common thing we correct on an incoming specification, and it costs real money. WiredTiger encryption at rest is an Enterprise feature. The MongoDB manual says so in one line: available in MongoDB Enterprise only. It is not in Community. So when a proposal offers you MongoDB Community with WiredTiger AES-256 at a low monthly figure, one of three things is true. They are quoting a subscription they have not priced, they mean full-volume encryption and are calling it something else, or they have not read the page.
The two honest routes, and what each one gives you
Full-volume encryption with LUKS under the data directory gives you AES-256 at rest on any edition, and it defends exactly what a stolen or badly retired disk exposes. Percona Server for MongoDB is the other route: a drop-in build that implements the same encryption interface without the subscription, and it integrates with Vault, OpenBao and KMIP for the keys. We will run either, and we will tell you which one your compliance requirement actually needs. PostgreSQL sits differently again, because its core carries no transparent data encryption at all, so at rest there means the volume and anybody claiming otherwise is describing a fork or an extension.
The control that matters more than the checkbox
Encryption at rest answers a question about physical media. It says nothing about a credential in a repository or a reporting user with more rights than the report needs, and those are how database data actually leaks in this market. A private subnet with no public route, one rotated credential per application, read-only roles for analysts and audited human access over a VPN cost less than a subscription and stop more. That is the same argument we make on the security side of the house, and figure 03 above is the version we draw on a whiteboard.
Managed PostgreSQL, and the slow query nobody can see
Postgres is the engine we run most, and the pattern is consistent: the database is not slow, four queries are. Finding them is a solved problem the moment somebody turns on the instrumentation and then goes and looks, which is the part that does not happen when nobody owns the database. Our strongest published record here is an embedded engagement inside an existing AWS platform team, where a slow-query observability path was built across four repositories and a 137-database inventory was made to regenerate itself from the live estate. The counts on that case study are taken from the repositories rather than written by marketing, and most of the work was in failures that report success.
Database administration without hiring a full-time DBA
Very few organizations in this market can justify a dedicated database administrator, and almost all of them need one about four days a quarter. That is what a remote DBA retainer is for: the upgrade calendar, the index review, the connection pool nobody sized, the replication that has been broken since a maintenance window in some earlier quarter, and the restore test that proves the backups are real. It sits alongside the delivery and automation work where the schema changes come from a pipeline rather than from a laptop.
MySQL, MariaDB, and when Galera is the wrong answer
Galera looks like the obvious upgrade from a primary and a replica, and for a write-heavy application it frequently is not. Every write has to be certified across the cluster, so a workload with hot rows and long transactions gets slower and starts throwing conflicts that the application has to handle. An asynchronous replica with a documented promotion path is often the better engineering answer, and we will say so even though the cluster is the bigger sale. Where Galera does fit, it fits well, and the deciding factor is your write pattern rather than anybody's preference.
Where your database can legally sit in Kenya
Database residency is where the residency question gets sharp, because a database is the one component that unambiguously holds the personal data. The Kenyan rule most businesses are subject to is not a location rule at all: the Data Protection Act governs the transfer, and regulation 26 of the 2021 general regulations imposes in-country processing only for a short list of state-interest purposes, satisfiable by keeping a serving copy in Kenya rather than by moving the primary. That distinction is worth real money on an architecture. We wrote the four-country version of this for Kenya, Tanzania, Uganda and Zambia in where your servers can legally live in East Africa.
Moving the database and leaving the application abroad
This is the design error we see most often, and it is expensive because it is discovered late. If the database moves to Kenya and the application tier that reads it stays on a platform in another country, the processing is still happening abroad and the transfer question is unanswered. The data has not come home, it has acquired a longer round trip. Either both tiers move together or the residency claim needs rewriting, and the second option is usually worse. Where the application also has to move, the shape of that is a private platform in Kenya rather than a database engagement on its own.
If a regulator licenses you, a stricter instrument may apply
A licensed institution has a second layer above the data protection law, and it can close a door the act leaves open. Buying a managed database is capable of being material outsourcing, which for a bank means prior approval before the arrangement is entered into rather than a notification afterwards. We set out what that submission has to contain in our read of the CBK outsourcing guideline. Tell us your license class in the form and we will tell you which instrument governs the placement, including when the honest answer is that your regulator, not us, decides where this can run.
Backups, replicas and which one gets your data back
A replica is a copy of your current state, including the state you did not want. Replication applied the delete faithfully to all three nodes inside the replication interval, which on a local link is milliseconds, and failover now hands you the same wrong data with a different hostname. The control that recovers from a bad write is a base copy plus a log archive, replayed to a point you choose, and the control that recovers from ransomware is that copy sitting under a retention lock nobody can shorten, including your own administrators and including us. Figure 02 above is this argument in one drawing, and the wider version of it lives in the disaster recovery practice.
- Base copy plus log archive: pgBackRest for PostgreSQL, oplog archiving for MongoDB, binary logs for MySQL. This is what turns a database backup into point-in-time recovery rather than a word in a proposal
- Retention lock on the object copy: object storage with a lock, so the credential that deletes your data cannot delete the copies of it
- A restore every month into a throwaway instance: with the elapsed time recorded, because a recovery estimate nobody has measured is a guess presented as a number
- Logical and physical copies both: a physical copy restores fast and carries corruption with it, a logical dump is slower and gives you a single table back on a Tuesday afternoon
- Retention laddered on purpose: daily for a fortnight, weekly for a quarter, monthly for as long as your own rules require, rather than everything forever because nobody chose
When we tell clients not to buy a managed database
We run these for a living and we still talk people out of them regularly. Saying it out loud is the difference between an engineer and a reseller with a diagram.
- Your database is 6 GB, it serves twelve internal users, and it has never fallen over. Buy the backup discipline and a monthly restore test, and keep the rest of the budget
- The application is the problem. If a page makes forty queries to render, a bigger database instance buys you a few months and the same conversation later. Fix the queries first, and we would rather help with that
- You want three nodes because a spec sheet said three nodes. If your write rate is a dozen operations a second, a primary and a standby with a written promotion path covers the real risk at a fraction of the price
- Nobody has restored from your current backups. That is the whole engagement until it is done, and it is a week of work rather than a platform migration
- You are moving the database to Kenya for residency but leaving the application abroad. That does not achieve the thing you are buying it for, and we will say so before you commit
- A dedicated database administrator would genuinely be cheaper for you than a retainer. It happens at a certain size, and when it does we will help you write the job description and hand over to the person you hire, which is closer to how the support relationship is scoped anyway
What you own when we hand the database over
Everything, and nothing that only works while we hold a password. You get the provisioning and configuration as code in your own repository, the backup and retention configuration with the reasoning behind each number, the monitoring and its alert rules, the runbooks for promotion and restore, and the measured timings from the drill your own people ran with us watching. Credentials sit in your vault. The engines are open source or a drop-in build of one, so nothing here needs us to keep working. Plenty of clients take the build, the first restore test and the documentation, then run the calendar themselves on top of Linux platforms we set up with them, and that is a good outcome we scope for openly.
Tell us what the database has to survive
Enough for a real design and one figure rather than a range. Every field has an escape hatch, so answer what you know and leave the rest to the review.
Ready to discuss Managed Databases?
A 30-minute scoping call, free, and it commits you to nothing.
How Every Managed Databases Engagement Starts
Read the estate first
A free session, then we look at your real numbers: data and index size, write rate, log growth, connection counts and the slowest queries. Sizing comes out of that, never out of a template.
Design, then one price
The shape, the node count, the recovery window, the residency position and what the old platform did that the new one must be taught. Written down, with a single scoped figure and the reasoning.
Rehearse, then cut over
We restore into a throwaway instance and time it before touching production. Then the cutover happens in a window you choose, with a rollback point and somebody watching the application.
Run it and prove it
Monitoring, patching, a monthly restore test, a failover drill on the calendar, and a quarterly review of slow queries, capacity and cost. The evidence is the deliverable.