A managed database service runs your databases for you: provisioning, tuning, replication, backups, security and the upgrades, so your team builds on the data instead of nursing the engine under it. In 2026 the database is also the sharpest sovereignty question you have, because it holds the personal data the rules are written about, and it is the system whose failure hurts most. Argus Root runs the open-source engines — PostgreSQL, MySQL, Redis — inside the EU, with high availability, point-in-time recovery and pgvector for AI built in.
In short
- PostgreSQL is the dominant open-source database and is steadily replacing Oracle and SQL Server, dropping a licence that is among the largest and least-loved lines in many IT budgets.
- High availability makes a node failure a non-event: automatic failover under ~60 seconds to a standby, with synchronous replication for zero data loss and SLAs up to 99.99%.
- Point-in-time recovery restores to any moment within a 30–35 day window, so it undoes the bad migration or the wrong DELETE, not just a dead disk.
- pgvector turns the database you already run into your AI vector store — semantic search and RAG retrieval without standing up a separate system.
- The managed-versus-self-hosted call is simple: building HA, monitoring and failover yourself takes weeks of engineering, so you want managed once the cost of downtime exceeds the management fee.
Managed databases, open-source and operated inside the EU.
Your database is where the regulated data really lives, so where it sits and who can reach it matters most here. We run PostgreSQL, MariaDB and MySQL ourselves, inside the EU, tuned for your workload with recovery you can trust.
The bar for a database you can rely on.
Managed services have raised what a production database is expected to deliver, and the same bar applies whether the engine is open-source or not. The difference is who operates it and where. We hold to the 2026 standard, on infrastructure inside the EU rather than a tenancy that keeps a foreign parent in the chain.
| Capability | The 2026 bar | Argus Root |
|---|---|---|
| Encryption | At rest and in transit | Yes |
| Access control | Fine-grained RBAC | Yes |
| Backups | Automated, point-in-time recovery | Yes |
| High availability | Automatic failover under 30s | Replicated, automatic failover |
| Audit | Query and access logging | Yes |
| Residency | GDPR-aligned | EU, operated by us |
The bar is higher than most self-run databases clear. A database the business depends on needs availability that survives a node failing, recovery that can undo a mistake rather than only a disk loss, patching that happens without an outage, and performance that holds as the data grows. Managed services have made these table stakes, automatic failover, point-in-time recovery, near-instant patching, but a database administered in spare time rarely has all four, and discovers the gap at the worst moment.
The reason the bar matters is what sits below it. The database is usually the single most important system a business runs, the place the orders, the customers and the records really live, and its failure is rarely a degraded mode; it is a full stop. A slow database drags every application that depends on it, and a lost one can end the business outright. Treating it as infrastructure operated to a standard, rather than a server someone occasionally checks, is the difference between a quiet dependency and a recurring crisis.
Open source, no licensing trap.
PostgreSQL has become the default for new development, and enterprises are steadily moving workloads off Oracle to escape its licensing bill while keeping only the cores that genuinely need it. Open-source engines remove the per-core meter and the lock-in: your data stays portable, on standards you can move to another operator without a rebuild.
We run the open-source lane on purpose: PostgreSQL, MariaDB, MySQL and Redis, the engines we operate under our own applications every day. If your estate is Oracle or SQL Server at the core, that is a different specialism, and we will say so rather than pretend otherwise. Where it fits, we help offload the surrounding systems to Postgres and bring the cost down. See managed cloud for the repatriation side.
The momentum behind Postgres is hard to overstate. With version 18 shipped in late 2025 and an extension ecosystem that keeps widening, it now matches the proprietary engines on the core work most applications really do, and adds capabilities, pgvector for similarity search, PostGIS for geospatial, time-series extensions, that used to mean buying a separate product. The companies running the largest workloads in the world, Apple, Uber and Netflix among them, run open-source engines, which settles the old question of whether they are enterprise-grade. They are; the licence is simply free.
What do we run for you?
The data layer first, because most performance problems start in the query, not the hardware.
Tuning & indexing
We start at the data layer: query plans, indexes and schema, which often removes the need for the hardware upgrade a slow database seems to demand.
Replication & high availability
Primary and replica topologies with automatic failover, so a node loss is a non-event rather than an outage your customers feel.
Backups & point-in-time recovery
Automated backups with the ability to restore to a moment before the mistake, kept in-region and tested. See backup & DR →
Security & audit
Encryption at rest and in transit, fine-grained access control and audit logging, the controls GDPR and your customers expect of the system that holds their data.
Migration & upgrades
Engine upgrades and moves handled with tested cutovers, including Oracle-to-Postgres offloads and repatriation from a cloud DBaaS you have outgrown.
Monitoring
Slow-query tracking, replication lag and capacity watched continuously, on the same footing as the rest of your infrastructure.
We run these databases under our own systems.
The engines we manage for you are the ones our own platforms depend on, tuned and replicated on infrastructure we operate inside the EU. We optimise the query before reaching for a bigger server, because the data layer is where the speed and the cost both hide. When your database holds personal data, keeping it on EU infrastructure we run means the regulated data itself stays out of foreign reach. See compliance & sovereignty.
# high availability: synchronous standby = zero data loss wal_level = replica max_wal_senders = 10 synchronous_standby_names = 'replica1' hot_standby = on # replicas serve reads # point-in-time recovery: ship WAL to EU object storage archive_mode = on archive_command = 'restic backup %p -r s3:eu-central/db-wal' # AI vectors in the DB you already run — no separate vector store -- CREATE EXTENSION vector; -- embedding vector(1024); CREATE INDEX ON docs USING ivfflat (embedding);
A node failing should be a non-event.
Hardware fails, networks drop, and a process dies; the question is whether your database notices for your customers or only for you. High availability answers it with a primary and one or more replicas kept in sync, so when the primary fails a standby is promoted automatically and the application keeps serving, with a gap measured in seconds rather than the hours a manual recovery from backup would take. A single-instance database is a single point of failure with your most important data behind it.
We run primary-replica topologies with automatic failover and the monitoring to drive it, so a node loss is the non-event it should be rather than the outage your customers feel. The replicas also earn their keep in normal operation, taking read traffic off the primary so the database serves more without growing, and standing ready as the warm copy a recovery would otherwise have to rebuild. Availability is an architecture decided in advance, not a hope you hold the first time a disk dies.
Recovery that undoes the mistake, not the disk alone.
Most database disasters are not hardware; they are a bad migration, a wrong delete, a deploy that corrupted data, a mistake made at 4pm that nobody noticed until 6. A nightly backup helps with a lost disk and barely at all with this, because restoring last night loses the day. Point-in-time recovery is the answer: using the database's write-ahead log, it can restore the data to an exact moment, the instant before the bad change, rather than to whenever the last full backup happened to run.
We run PITR as standard, with the recovery points kept in-region and the restores tested rather than assumed, because a recovery path nobody has exercised is a guess. It turns the worst kind of database incident, the self-inflicted one, from a catastrophe into a rewind: the bad migration is undone to the second before it ran, and the hours of good data after it are not collateral damage. The deeper recovery planning sits with our backup and disaster recovery work; at the database layer, being able to go back to a precise moment is what makes a human mistake survivable.
Does a slow database need a bigger server?
When a database is slow, the reflex is to throw hardware at it, and the reflex is usually wrong. The slowness almost always lives in the data layer: a query doing a full table scan for want of an index, a schema that fights the access pattern, a handful of expensive statements dragging everything behind them. Scaling the server makes the symptom briefly less painful while leaving the cause in place, and the cost recurs every month for a problem an afternoon of tuning would have removed.
So we start at the queries, the indexes and the schema before touching the instance size. Finding the statements that cost the most, adding the index that turns a scan into a lookup, reshaping a query that the planner cannot optimise, this is where the largest, cheapest gains live, and it often removes the hardware upgrade a slow database seemed to demand. Where the work genuinely has outgrown the machine, we say so and scale it, but only after the data layer is doing its job, because paying for hardware to paper over a missing index is the most common waste in database operation.
How do you escape the Oracle and SQL Server licence?
Proprietary database licences are among the largest and least loved line items in many IT budgets, metered per core and rising with every audit. PostgreSQL has become the standard landing spot for organisations leaving them, feature-comparable on the core transactional work and free of the per-core meter, which is why the migration off Oracle and SQL Server has become a steady movement rather than an occasional brave experiment. The licence saving alone often pays for the move several times over.
The pattern that works is rarely a single heroic switch. More often we keep the core system where it genuinely needs to be and offload everything around it, the reporting, the integrations, the secondary applications, to Postgres, which removes the licensing from a large part of the estate without betting the crown jewels on a one-step migration. We assess which workloads move cleanly and which carry real risk before committing to anything, and we are honest about the cases where the dependency on a proprietary feature makes staying the right call for now. The goal is the licence bill cut by as much as safely can be, rather than a migration crusade that moves things that should not move.
The database is your sharpest sovereignty question.
Of everything you run, the database is where the regulated data physically lives: the personal records, the customer details, the very data GDPR and NIS2 are written about. That makes its jurisdiction the question that matters most, and the one a residency badge does not settle. A database service owned by a US company, even running in an EU region, keeps the parent within reach of the CLOUD Act, which means the regulated data itself, not a copy, not a log, the data, is reachable by a foreign authority.
We run the database on infrastructure we operate inside the EU, with no foreign parent in the chain, so the data that draws the most regulatory scrutiny has the cleanest possible answer to where it sits and who can compel it. For a regulated business this is often the single most important placement decision in the estate, because the database is both the highest-value target and the highest-stakes compliance question, and getting it onto sovereign infrastructure removes a risk that a hosting location alone never could. The regulatory framing follows our compliance work.
Security and audit at the data layer.
A breach of the database is the breach that matters, because it is where the data an attacker really wants is concentrated. Securing it is a layer of its own: encryption at rest so a stolen disk is useless, encryption in transit so the connection cannot be read, and access control fine-grained enough that an application or a person can reach only what they need rather than the whole store. The default configuration of most databases is far more open than it should be, which is how a single compromised credential becomes a full data breach.
We harden the database to that standard and add the audit logging that both regulators and incident response depend on: a record of who accessed what and when, so an investigation has facts rather than guesses and an auditor has the evidence GDPR expects. Detection and response across the wider estate run with our managed security, and the database sits inside that picture rather than as an unwatched store behind the application. The system holding your most sensitive data should be the most carefully secured, not the one left at its installation defaults.
Can your database do AI vectors?
The database has quietly become part of the AI stack. Retrieval-augmented generation, the pattern that grounds a model in your own documents, needs a vector store to find the relevant passages, and pgvector gives PostgreSQL that capability without bolting on a separate specialist database. For a great many AI projects, the vector search that moves them from pilot to production can run in the database the data already lives in, which is simpler, cheaper and keeps the data in one governed place.
That matters for sovereignty as much as simplicity. The documents and embeddings fed to a model are often the sensitive material that should not leave the EU, and keeping the vector store inside the same sovereign database avoids shipping it to a separate cloud service to be searched. We run pgvector and the surrounding extensions as part of the managed engine, and where an AI workload needs the search performance of a dedicated vector database we say so; for most, the capability in Postgres is enough, and the part of the AI system that touches your data stays where the rest of it is. The building side sits with our RAG and knowledge systems work.
Repatriating a DBaaS you have outgrown.
A managed database from a hyperscaler is convenient until the bill is read closely. At scale, the premium on a public-cloud DBaaS over the same engine operated on EU infrastructure is large, often a difference of half the cost or more, and it grows with the data. The convenience that justified it for a small workload stops justifying it once the database is big, steady and central, which is exactly when the spend is highest and the case for moving is strongest.
Because the engines are the same open-source ones, moving off a cloud DBaaS is a managed migration rather than a rewrite: the data and the schema come across to a database we operate, tested in parallel and cut over with a tested rollback, the same discipline as any other move. The result is the same PostgreSQL or MySQL your application already speaks, on sovereign infrastructure at a fraction of the cost, with the management you were paying the hyperscaler for still in place. We model the saving honestly before recommending the move, since the convenience of a DBaaS is real and worth keeping for a workload that has not yet outgrown it.
Upgrades and patching without the outage.
Databases fall behind because upgrading them feels dangerous, and a database left on an old version is both a security risk and a performance one. The fear is reasonable: a careless major-version upgrade can break an application or, done without a rollback, leave you stranded. The answer is the same discipline as any other change, a tested upgrade on a copy first, a rehearsed path, and a way back, so the upgrade is a routine maintenance step rather than a gamble taken once a year and dreaded.
We keep the engines current with minor patches applied on a cadence and major upgrades planned, tested and reversible, with the failover topology used to apply them with little or no downtime. An end-of-life database version, past its security support, is treated as a migration to plan rather than a risk to carry, the same way we treat an end-of-life operating system. The point is that staying current stops being the thing nobody dares do, so the database is patched and supported rather than frozen on an old version because upgrading was too frightening to attempt.
Scaling reads, writes and the right shape.
Databases do not scale like stateless application servers, which is why naive scaling so often disappoints. Read traffic scales well across replicas, so a read-heavy workload can grow by adding read replicas and pointing queries at them. Write traffic is harder, bound to the primary, and the answer there is more often tuning, connection pooling and schema work than a bigger box, because a write bottleneck is usually a design question rather than a capacity one. Knowing which kind of load you have is half of scaling it.
We scale to the shape of the workload rather than reach for the largest instance by reflex. Connection pooling stops a flood of connections exhausting the database, read replicas absorb the reporting and analytics load that would otherwise compete with live traffic, and the heavy writes are addressed where they genuinely originate. Vertical capacity is added when the work genuinely needs it, after the cheaper levers are pulled, so you grow the database deliberately rather than discover at a spike that more hardware was never the bottleneck.
The database that stays healthy.
A database degrades quietly. Tables bloat, statistics drift, indexes fragment, slow queries creep in as the data grows, and a system that was fast at launch becomes sluggish over months without any single dramatic failure to point at. The work that keeps it healthy, vacuuming, refreshing statistics, watching replication lag and slow-query trends, managing capacity before it runs out, is the unglamorous routine that an unmanaged database simply does not get until something breaks.
We run that day-two maintenance continuously, watching the signals that predict trouble and acting on them before they reach the application, on the same footing as the rest of the infrastructure we operate. Slow-query tracking surfaces the statement that is starting to drag, replication lag is caught before it becomes a stale read, and capacity is added ahead of the wall rather than at it. The aim is a database that stays as fast and reliable in its third year as its first, because the slow degradation of a neglected database is the failure that creeps up on more businesses than any sudden crash.
Who needs this, and when do you not?
Managed databases fit when the database has become too important to run on luck: a business whose application depends on it being fast and available, an organisation under GDPR or NIS2 whose data needs to sit somewhere demonstrably sovereign and secure, a team with no database administrator and no wish to hire one, or anyone facing an Oracle bill, a slow production database, or a DBaaS that has grown expensive. The common thread is a database carrying real weight without anyone whose job is to keep it healthy.
Where the database is small and undemanding, we will say so. A modest application database with light traffic and no sensitive data is often served perfectly well by the database that comes with our managed hosting, and paying for a dedicated managed database it does not need would be waste. The case for this service is strong where the database is large, central, regulated or struggling, and weak where it is none of those, and we would rather place you on the right side of that line than sell the heavier service to a workload that does not call for it.
Caching that takes load off the database.
The fastest database query is the one you never run. A cache layer holds the results that are read often and change rarely, so the database is spared the repeated work of answering the same question, and the application gets its answer in microseconds rather than waiting on a round trip. For read-heavy workloads, a well-placed cache does more for performance than any amount of database tuning, because it removes the load rather than serving it faster.
We run Redis as that layer where it fits, for caching, sessions and the fast key-value work it excels at, managed on the same in-region, secured footing as the databases behind it. The art is in what to cache and for how long, since a cache serving stale data is its own kind of bug, so the caching is designed around the access pattern rather than switched on blindly. Used well, it lets a modest database serve a large, busy application, which is often cheaper and more reliable than scaling the database to absorb load a cache should have caught.
The evidence a regulator and a customer ask for.
Because the database holds the regulated data, it is also where the hardest compliance questions land, and the answers have to be demonstrable rather than asserted. Where does the data sit, who can reach it, how is it encrypted, can you show who accessed it, and can you prove you could recover it. For a regulated business or one passing a customer's security review, these are not abstractions; they are line items an auditor or a procurement team works through, and a database that cannot answer them is a finding.
We run the database so the answers exist as a matter of course: EU residency on infrastructure we operate, encryption documented, access logged, recovery tested, all producible rather than reconstructed under deadline. The data-protection framing follows our compliance work, and the recovery evidence our backup and disaster recovery practice, so the database layer of an audit stops being the part nobody can speak to confidently. The system holding the most sensitive data should be the easiest to answer questions about, rather than the one that triggers them.
How does it start?
An engagement opens with two honest tests of where you stand: the queries that are hurting, and whether your backup would truly restore. The slow-query picture shows where the data layer is struggling and how much of it is tuning rather than hardware; the backup test shows whether the recovery you are relying on is real or assumed. Both usually surface more than expected, because a database administered in spare time tends to hide its problems until they are acute.
From there we bring the database to a known standard, tuned, replicated, backed up with tested point-in-time recovery, secured and monitored, in a planned sequence rather than all at once, so nothing breaks in the name of improving it. Then it becomes the standing routine: the day-two maintenance, the patching, the watching, run continuously. The aim is a database that stops being a source of quiet anxiety and becomes a dependency you do not have to think about, which is what a managed service should deliver for the most important system most businesses run.
Questions buyers ask.
What is a managed database service?
Which database engines do you support?
Why does database residency matter more than other workloads?
Can you move us off Oracle to cut licensing costs?
How do you handle high availability and backups?
My database is slow. Do I need a bigger server?
How do you keep the database available if a server fails?
What is point-in-time recovery, and why does it matter?
Can you run vector search for AI in our database?
Is a managed database cheaper than a cloud DBaaS?
How do you handle database upgrades safely?
How do you secure the data itself?
Do we even need a managed database, or is hosting enough?
Send us your slowest query and your backup setup.
Tell us what you run and where it hurts: latency, a fragile failover, a licensing bill, or data sitting under foreign jurisdiction. We report what we would change and what it would take, before you commit to anything.