A DigitalOcean Managed Databases alternative: one plan instead of a cluster per engine

DigitalOcean Managed Databases sells each engine as a separate cluster. At the smallest sizes on its current pricing page, Postgres, Valkey, and MySQL add up to $45.30 a month. Layerbase Pro is $15 a month for up to 10 databases across 18 Cloud engines, sharing a capacity pool. Those are different amounts of hardware, so compare both the bill and the resources your app needs.

I build Layerbase. The reason I would consider it here is a small stack that needs several engines and database branches without a separate monthly minimum for each engine. DigitalOcean has advantages too, especially VPC networking and managed high availability.

Updated October 2026

DigitalOcean is changing what you can create on PostgreSQL and MySQL Standard Edition. New Standard clusters will be limited to the 1, 2, and 4 GiB Basic - Shared CPU plans, with no standby or read-only nodes. Larger new clusters and those node types require Advanced Edition.

Existing clusters are unaffected by this plan change. DigitalOcean says they can still be resized, forked, restored, and given standby or read-only nodes, including on plans no longer offered for new clusters. Advanced also gains 8-64 GiB shared-CPU plans on October 15. DigitalOcean's plan-change announcement covers the account definitions and exceptions.

For a new small, single-node app, Standard remains an option. If you need managed failover or read-only nodes, check Advanced before deciding on a size. This announcement changes plan availability; it does not establish a price increase. Compare the configurations on the current pricing page.

Check scripts that create clusters

Review Terraform, doctl, and API create operations before your account's cutoff. A script selecting a Standard plan above 4 GiB, or requesting standby or read-only nodes on a new Standard cluster, will no longer describe an available configuration. Check updated provider references rather than guessing new plan identifiers. DigitalOcean explicitly calls out these automation paths in its announcement.

MySQL 8.0 upgrades start October 30

There is a separate change for existing databases: managed MySQL 8.0 clusters are scheduled for forced upgrades to 8.4 during their maintenance windows, starting October 30, 2026. Review your window and test your application's compatibility before then. DigitalOcean says these updates have no downtime, though brief latency can occur. The MySQL upgrade notice has the details.

If you are already planning a migration, choose the target version deliberately. Layerbase MySQL currently offers 8.4 LTS and 9.7, with 9.7 the default. Moving providers is a chance to choose a supported version; it is still worth testing the schema, queries, and application against that version before cutover.

Advanced Postgres extension support changed too

On September 30, DigitalOcean stopped allowing additional CREATE EXTENSION installs on Advanced Postgres. On October 6 it enabled 20 additional extensions beyond the pre-installed set, including pg_trgm, pgcrypto, and citext. Check the current allowlist for the extensions your app uses. The release notes and Postgres limits describe the current support.

What DigitalOcean Managed Databases actually is

Six managed engines: PostgreSQL, MySQL, Managed Caching for Valkey, MongoDB, Kafka, and OpenSearch. Each one is provisioned as a cluster. A cluster has a size, a node count, a private network attachment, and a bill.

Access can be restricted with trusted sources, a per-cluster allowlist of resources or IP addresses. Postgres connections require TLS, and you can select the public or VPC-private connection details for the path you use. DigitalOcean's security guide covers trusted sources and certificate verification.

None of this is bad. It is a well-built managed database product from a company that has been running infrastructure for a long time. The question is whether its unit of sale matches the shape of your app.

The pricing shape

Entry prices in USD, verified October 13, 2026 from DigitalOcean's managed databases pricing page. Postgres and MySQL here are Standard Edition, Basic Regular, with no additional nodes and the minimum displayed storage. These are the page's monthly figures:

Now compose an app. Not an ambitious one: Postgres for the data, a Valkey cache in front of it, and a MySQL database because some service you inherited needs one.

PostgreSQL   $15.15
Valkey       $15.00
MySQL        $15.15
             ------
             $45.30 / month

That is three of the smallest listed clusters. It establishes the starting bill, not whether those sizes will handle your production workload.

Layerbase Pro is $15 a month for up to 10 databases across every engine we host. It includes a 1.5 GB always-on RAM pool, 1 vCPU, and 25 GB storage, shared across your stack. It is not three separate 1 GiB nodes, and keeping several engines always on may require more capacity. Pool blocks cost $10/month each and add 1 GB RAM, 1 vCPU, and 25 GB storage. Solo is $5 a month for two databases and 10 GB storage, with a 768 MB pool that keeps one database awake. Free is $0 for two databases and 5 GB, with sleeping databases and no card. Layerbase pricing gives the capacity and plan limits.

Free is for development, testing, and early-stage projects. A product running in production and earning recurring revenue belongs on Solo or Pro. Choose the capacity for the databases you want awake together; the database count alone does not tell you that.

The Kafka starting price reflects DigitalOcean's three-broker minimum. It is a separate product and budget decision from adding a small cache.

What DigitalOcean does well

I am not going to pretend the answer is always us.

VPC-private networking. Your cluster can be reachable only from inside your VPC, and the panel hands you the private connection string for it. If your compute is already on DigitalOcean Droplets or DOKS, that is a real security posture with almost no work, and it is the single strongest reason to keep a database there.

Real MongoDB. DigitalOcean offers managed MongoDB. We cannot, for licensing reasons, so what we host is FerretDB: the MongoDB wire protocol on PostgreSQL. That covers a lot of applications and does not cover all of them. If you depend on features FerretDB does not implement, DigitalOcean has something we do not.

Kafka and OpenSearch. We do not host either one. If your architecture needs a managed event log or a managed search cluster of that class, that is not a gap you can argue your way around, and $148.80 for three Kafka brokers is a real price for a real thing.

Everything else on one invoice. If your Droplets, load balancers, Spaces, and databases are already DigitalOcean, consolidating on the vendor you already have is worth something on its own.

Where it gets awkward

Each additional engine has its own minimum. One database can be a comfortable fit. As a cache, a search service, or another SQL engine joins the app, each cluster adds a starting price. We cover the broader budgeting problem in the multi-database tax.

Valkey defaults to noeviction. This is the one that catches people. DigitalOcean's default eviction policy on a Managed Caching cluster is noeviction, and their docs recommend allkeys-lru for cache workloads, but you have to go and select it. A cache with noeviction does not evict; it fills up and then starts refusing writes. If you have ever had a cache mysteriously start erroring under load on DigitalOcean, check this setting before you check your code.

Network access needs to match the caller. Trusted sources can restrict database connections, and DigitalOcean currently does not support IPv6 trusted-source rules. An app inside your VPC and a migration service outside it use different network paths. Check the allowlist and connection details before starting a copy. The controls live under Network Access and are documented here.

What Layerbase does instead

On Pro, one plan covers up to ten databases across 18 Cloud engines, with a shared pool for always-on capacity. You create databases inside that plan and size the pool for what you need running together.

Three things follow from that shape that are hard to get from a cluster-per-engine product:

Branching. 16 of our engines support copy-on-write branches. Each branch has its own writable data and connection string, within the plan's branch, storage, and capacity limits. Our Vercel and GitHub integrations can wire branches into preview workflows. That makes a test copy part of the development setup, without a separate cluster subscription for each copy. See database branching.

Hibernation. Standard engines can sleep when idle and wake on connection. Paid plans add a pool for the databases you want pinned always on. Sleeping changes resource use; it does not add or subtract a usage charge from the plan. The lifecycle guide explains sleep and Free-tier archiving.

A free tier that is not a trial. $0 for 2 databases and 5 GB, no card, across 8 engines including Postgres, Valkey, and MariaDB. There is no equivalent to that in a product where the smallest unit is a $15 cluster.

Point-in-time recovery is available for PostgreSQL and FerretDB on Pro and above, with an always-on pin and PITR enabled. That is recovery from a log, not automatic failover to a standby. Layerbase does not offer managed standby nodes, read replicas, or automatic database failover. If you require those, compare DigitalOcean Advanced Edition on those requirements. Our recovery feature details describe the scope.

Moving the data

Both Postgres and MySQL on DigitalOcean are the upstream engines with no proprietary protocol, and Managed Caching is Valkey, which is what we host. So the moves are ordinary: a schema and data copy, then a connection-string change.

Paste the connection string on the DigitalOcean migration page. We read it once, copy schema and data into a managed Layerbase database, verify counts against the source, and report anything that did not come across. Your DigitalOcean cluster is never written to.

Check trusted sources before starting. An empty list permits public connections; adding trusted sources restricts access to those sources. A copy from outside your VPC needs a reachable public endpoint. Keep existing application rules and add only the migration service's source IP temporarily, then remove that temporary rule after the copy. Clearing the list opens public access, as DigitalOcean's migration docs explain. If the cluster must stay private or that path is unavailable, export from a machine already allowed to connect and import the dump separately. DigitalOcean does not support IPv6 trusted-source rules.

Grab the string from the cluster's connection details panel, and take the public network format if you are copying from outside the VPC. The private connection needs a path into that VPC.

When to stay on DigitalOcean

These are good reasons to keep the database there:

• Your compute is on DigitalOcean and your database is VPC-private. Keeping a private network path is a useful reason to keep the database alongside that compute. A migration needs a network-access plan as well as a price comparison.
• You need managed failover or read-only nodes. Advanced Edition is the DigitalOcean option for new clusters after the cutoff. Layerbase is not an equivalent for those requirements. Existing DigitalOcean clusters retain their current options under the announced plan change.
• You need Kafka or OpenSearch managed. We do not host either. Nothing else in this post matters if that is your requirement.
• You need real MongoDB, not the wire protocol on Postgres. Check your application against the FerretDB compatibility rundown before assuming either way, but if you land on the wrong side of that list, stay.
• You run exactly one database and it is comfortable. One Postgres cluster at $15.15 a month is a fair price for a well-run managed Postgres. The argument in this post is about composition, and at one engine there is nothing to compose.

The case for moving is strongest when you are running three or four engines, each on its own cluster, each at the smallest size, and the sum has quietly become the largest line on your infrastructure bill for databases that are mostly idle.

FAQ

How much does DigitalOcean Managed Databases cost?

At the smallest sizes listed on the pricing page, verified October 13, 2026: Standard PostgreSQL $15.15 a month, Standard MySQL $15.15, Valkey $15.00, and MongoDB $15.23. OpenSearch starts at $19.60, and the smallest listed three-broker Kafka cluster is $148.80. Advanced Edition and additional nodes are separate configurations; use the pricing page for those quotes.

Do the October changes affect my existing DigitalOcean cluster?

The Standard/Advanced plan restrictions apply to new clusters after your account's cutoff. Existing clusters retain their current options, including resizing and additional nodes. The MySQL 8.0 upgrade notice is a separate policy that does apply to existing MySQL 8.0 clusters, starting October 30 during maintenance windows.

Why does running three engines cost three times as much?

Because each engine is its own cluster with its own minimum. Postgres, Valkey, and MySQL at entry size is $15.15 plus $15.00 plus $15.15, which is $45.30 a month before any traffic. Nothing about the second and third cluster is discounted; each is priced as a standalone product.

What is the DigitalOcean equivalent on Layerbase?

One plan instead of a cluster each. Pro is $15 a month flat for up to 10 databases across 18 Cloud engines, so a three-engine stack counts as 3 of your 10 on one bill. Those databases share Pro's 1.5 GB RAM pool, 1 vCPU, and 25 GB storage; size the pool for what you want awake together. Free is $0 for 2 databases and 5 GB with no card, and Solo is $5 a month for 10 GB. Capacity past the plan's pool grows in $10/month blocks adding 1 GB of RAM, 1 vCPU, and 25 GB of storage.

Why did my DigitalOcean Valkey cache start refusing writes?

Check the eviction policy and memory usage. The default on a Managed Caching cluster is noeviction, which can cause writes to fail when memory fills. DigitalOcean's docs recommend allkeys-lru for cache workloads. Select an eviction policy that matches whether your application can discard those keys.

What should I check before copying a DigitalOcean database?

Check its trusted sources and the connection details for the network path you will use. An empty trusted-source list permits public connections. For a copy from outside the VPC, use a reachable public endpoint, preserve existing application rules, and temporarily allow only the migration service's source IP. Remove the temporary rule when the copy finishes. Use a trusted machine to export instead if the cluster must stay private. IPv6 trusted-source rules are not supported.

Does Layerbase host Kafka, OpenSearch, or MongoDB?

Kafka and OpenSearch, no. MongoDB, not directly: licensing prevents it, so we host FerretDB, which implements the MongoDB wire protocol on PostgreSQL, and your driver and connection string keep working for the ordinary paths. If your app depends on the features FerretDB does not implement, DigitalOcean's managed MongoDB is the right answer.

How do I migrate off a DigitalOcean database cluster?

Paste the connection string on the migration page and we copy schema and data in one read-once pass, verify the counts, and never write to your source. The step that trips people up is trusted sources: a cluster with any rule set is default-deny, so either add a temporary rule for the copy or run the export from a Droplet that is already trusted. Use the public connection string if you are copying from outside the VPC.

Starting

Before creating your first DigitalOcean database, compare the cluster bill and capacity with one flat Layerbase plan. If you are already moving, start at the DigitalOcean migration page and check the source network access. You can also create a fresh Postgres, Valkey, or MySQL database.

Methodology note

DigitalOcean prices and announcements were checked against its official pricing page, release notes, and product docs on October 13, 2026. Layerbase plans, version choices, and feature limits were checked against the current plan definitions, engine registry, and public docs. Prices are static in this post; check the provider's checkout before buying. The comparison is about pricing structure and workflow, not a benchmark or a claim of equal hardware or availability.