SkySQL alternatives: serverless MariaDB hosting in 2026

Short version: SkySQL is not gone, it is renamed. MariaDB plc shut its own DBaaS down in 2023, the product was spun out as an independent company, and in August 2025 MariaDB bought it back and relaunched it as MariaDB Cloud. So the shortlist for managed MariaDB in 2026 is MariaDB Cloud if you want it from the vendor, AWS RDS if your stack already lives there (Azure retired its MariaDB service in September 2025, so the Azure path is now MySQL), Layerbase Cloud if you want a flat monthly price and no cloud-provider account, and self-hosting if you have ops capacity and a small workload. For local development, the Layerbase CLI runs the same MariaDB binary on your machine.

If you're here because you wanted MariaDB-the-database, not MariaDB-the-vendor-relationship, this is the post for you. Below: the actual state of MariaDB hosting in 2026, what works, where the gaps are, and how Layerbase fits in.

Contents

• What SkySQL was, and what it is now
• The options at a glance
• Option 1: Layerbase Cloud
• Option 2: Run it locally with the Layerbase CLI
• Option 3: Layerbase Desktop
• Option 4: MariaDB Cloud, the rebuilt SkySQL
• Option 5: AWS RDS or Aurora, and what happened to Azure
• Option 6: Self-host
• MariaDB vs MySQL in 2026
• Which one to pick
• FAQ

What SkySQL was, and what it is now

SkySQL was MariaDB's own DBaaS. It ran MariaDB Enterprise and MariaDB Xpand (the distributed SQL product), supported the columnar engine for analytics, and was the canonical path for getting a MariaDB instance from the people who actually make MariaDB. MariaDB discontinued it in its original form in 2023 and the product was spun out as a separate company.

That is where this post used to end, and it is out of date: MariaDB plc acquired SkySQL Inc. back in August 2025, and the offering now ships as MariaDB Cloud, deployed on AWS, Azure, and Google Cloud. So the vendor-run option exists again, under a different name, which is why searching for "SkySQL" in 2026 turns up so much confusing material.

The two years in between still shaped the market. While the vendor option was gone, the canonical "I just want managed MariaDB" answer became "use AWS RDS," and most tooling and documentation still assumes that. That's fine if AWS is your platform. If you're on Vercel, Cloudflare, Fly, Railway, or anywhere else, you're looking at egress charges and a separate cloud-provider account just for the database.

The options at a glance

Option 1: Layerbase Cloud

Layerbase Cloud hosts MariaDB as a first-class engine. Create an instance, get a connection string, connect with any standard MySQL/MariaDB client.

Moving an existing database in is built into the create flow: pick Migrating from another platform and paste your current MariaDB or MySQL connection string, and it runs mysqldump once and copies the schema and data into the new instance. (On PlanetScale? Use a service token instead of a connection string and it pulls the database across for you.)

mysql -h <your-host>.cloud.layerbase.dev -P <port> -u layerbase -p<password> --ssl

The connection string format is the same shape you'd see for MySQL on any other host:

mysql://layerbase:password@<your-host>.cloud.layerbase.dev:<port>/<database>?ssl-mode=REQUIRED

One detail that's specific to managed MariaDB on Layerbase: MariaDB uses a dedicated TLS port per instance (rather than the SNI-routing trick we use for engines like Postgres). The server-speaks-first protocol that MySQL and MariaDB share doesn't expose a hostname during the TLS handshake, so we can't route them by SNI. The port appears in your connection string and the cert is valid for the database hostname.

Scale-to-zero works for MariaDB and the cold-start is quick (MariaDB doesn't have a JVM in the boot path). Backups are taken automatically. You can connect from any environment that has outbound network access to your instance.

If you've been on RDS MariaDB and want something simpler, smaller, and not tied to an AWS account, this is the option to try first.

Option 2: Run it locally with the Layerbase CLI

For local development, the Layerbase CLI (formerly SpinDB) is the fastest way to a real MariaDB instance on your machine. No Docker, no Homebrew tap, no brew services start mariadb ritual. (What is the Layerbase CLI?)

npm i -g layerbase        # npm
pnpm add -g layerbase     # pnpm

Create an instance:

lbase create maria1 -e mariadb --start

Get the connection URL:

lbase url maria1

mysql://root:password@127.0.0.1:3307/test

SpinDB downloads the MariaDB binary for your platform and runs it as a managed process. Same mariadbd binary the upstream project ships. No emulation, no fork, no compatibility layer. Standard MySQL clients work because MariaDB ships the same wire protocol.

lbase stop maria1
lbase start maria1
lbase list

The pattern that works well: the Layerbase CLI for local dev, Layerbase Cloud for staging and production. You're hitting the same binary in both places, so behavior matches.

Option 3: Layerbase Desktop

Layerbase Desktop is the same SpinDB experience wrapped in a desktop app. New instance, pick MariaDB, click create. Connection string shows up in the side panel, you can stop and start with a toggle. If you've ever installed MariaDB through Homebrew and lost an afternoon to permissions and my.cnf paths, Desktop avoids all of that.

For a developer who runs a few different databases on a laptop and doesn't want to keep their config in CLI muscle memory, this is the easiest way in.

Option 4: MariaDB Cloud, the rebuilt SkySQL

If you came here looking for SkySQL specifically, this is where it went. MariaDB plc reacquired SkySQL Inc. in August 2025 and now sells it as MariaDB Cloud, a fully managed DBaaS deployed across AWS, Azure, and Google Cloud, with serverless behaviour that scales down when the database is idle.

Three tiers are listed. Foundation is the free tier and runs the open-source Community Server. Power starts at $0.16 per hour and is pitched at mission-critical workloads. PowerPlus starts at $0.21 per hour and adds geo-distributed resilience and real-time analytics. Those hourly rates work out to roughly $117 and $153 a month if you leave an instance running continuously, and both are floors that move with the size you provision.

MariaDB Cloud rates verified 2026-08-25 from mariadb.com/products/cloud/pricing.

The reason to pick it is straightforward: it is MariaDB from the people who write MariaDB, with the Enterprise feature set and a support relationship attached. The reasons to look elsewhere are the same ones that apply to any hyperscaler-hosted database: the meter is hourly rather than flat, you are back inside a specific cloud's deployment story, and the entry price for the paid tiers is well above what a small app needs.

Option 5: AWS RDS or Aurora, and what happened to Azure

These are the incumbents and they work. RDS MariaDB is a managed wrapper around upstream MariaDB. Aurora MySQL is a fork by Amazon that's MySQL-compatible but not MariaDB.

Azure is no longer on this list. Azure Database for MariaDB was retired on 19 September 2025, and Microsoft's notice was blunt about the consequence: workloads still running on that date were deleted along with their data. The migration target Microsoft named is Azure Database for MySQL Flexible Server, which is MySQL, not MariaDB. If you were on Azure for MariaDB, the hyperscaler options are now RDS, or a MySQL that most MariaDB schemas will load into but that drops Aria, sequences, and the other MariaDB-only features on the way. Verified 2026-09-06.

The reasons to pick one of these:

• You're already deep in AWS and want everything in one account.
• You need the specific feature set (read replicas, automated failover, point-in-time recovery) at production scale.
• Your compliance posture requires the cloud vendor's specific certifications.

The reasons not to:

• The instance size you actually want costs more than the headline. In us-east-1, Single-AZ On-Demand RDS MariaDB runs $0.016/hour on db.t4g.micro, $0.032/hour on db.t4g.small, and $0.065/hour on db.t4g.medium. That is roughly $12, $23, and $47 a month before storage, backups, or egress, and the micro is too small for most real workloads. Doubling any of those for Multi-AZ is the usual next step.
• The setup involves VPCs, security groups, parameter groups, and a non-trivial number of dashboards.
• Egress charges add up if your application server is on a different cloud.

RDS MariaDB On-Demand rates verified 2026-08-25 from AWS's published RDS MariaDB pricing, us-east-1, Single-AZ, current generation.

For a startup or a side project, these are usually overkill. For a serious production database with HA requirements, they're a reasonable answer.

Option 6: Self-host

MariaDB self-hosts cleanly. The Debian and Ubuntu packages are well-maintained, the default my.cnf is sensible, and TLS is straightforward. If you have an existing VM (anywhere, including a $5 droplet) and don't mind running apt install mariadb-server and dealing with backups yourself, this works fine.

The two things that get people:

Default authentication on MariaDB 10.4+ is unix_socket for the root user on Linux. This is great for security and confusing the first time you try to log in over TCP. You either switch root to password auth or create a separate admin user with TCP-allowed credentials.

Backups are on you. MariaDB ships mariadb-dump and mariadb-backup (the physical backup tool). Neither runs itself. Set up a cron job and an off-server destination before you forget about the box.

For a small workload, self-hosting on a $5 VM is genuinely a great deal. For a serious workload, you'll spend more time on it than you'd like.

MariaDB vs MySQL in 2026

Quick sidebar because the question comes up: MariaDB and MySQL have continued to diverge. MariaDB has features MySQL doesn't (the SEQUENCE engine, ColumnStore for analytical workloads, JSON path syntax improvements, system-versioned tables, the Aria storage engine), and MySQL has features MariaDB doesn't (some WINDOW function refinements, the CLONE plugin, the INSTANT algorithm for some ALTER TABLE operations).

For most application code (CRUD against tables with indexes and foreign keys), they're still drop-in compatible. If you use any of the divergent features, pick the engine that has the feature you actually need and stay on it.

Layerbase Cloud supports both. If you can't decide, MariaDB is the safer default if you anticipate using JSON heavily or want the column store option later. MySQL is the safer default if you're betting on Oracle's continued investment in MySQL HeatWave-style features.

Which one to pick

Short version:

• Need managed MariaDB without an AWS account? Layerbase Cloud.
• Just need it running locally? The Layerbase CLI.
• Prefer a desktop app? Layerbase Desktop.
• Want MariaDB Enterprise and a support contract from the vendor? MariaDB Cloud, the former SkySQL.
• Already on AWS and need production-scale HA? RDS MariaDB.
• Have ops capacity and a small workload? Self-host.

MariaDB itself is in fine shape. The 11.x line is mature, the team is healthy, and the fork-from-MySQL story has aged well. The vendor-run hosting gap that SkySQL's shutdown opened has since been closed by MariaDB buying it back, but the cheap, flat-priced, cloud-agnostic on-ramp is still the thing the market is short of, and that's the part Layerbase Cloud fills.

FAQ

Is SkySQL still available in 2026?

Yes, under a new name. MariaDB plc discontinued its own SkySQL in 2023 and the product was spun out to an independent company; MariaDB then acquired SkySQL Inc. back in August 2025 and relaunched the offering as MariaDB Cloud on AWS, Azure, and Google Cloud. If you are searching for SkySQL and finding contradictory pages, that reacquisition is why.

What replaced SkySQL?

Nothing had to, in the end, because SkySQL came back as MariaDB Cloud. During the two-year gap the practical replacement was AWS RDS MariaDB, which is still where most tooling and documentation points, with self-hosting as the cheap route. Azure was briefly the other hyperscaler option and then was not: Azure Database for MariaDB was retired on 19 September 2025, with MySQL Flexible Server as the named replacement.

What is the cheapest managed MariaDB hosting?

MariaDB Cloud's Foundation tier is free, and Layerbase Cloud's free tier includes MariaDB, so both give you a running managed instance without a card. Past free, the shapes differ: MariaDB Cloud's paid tiers start at $0.16 per hour, RDS MariaDB starts around $0.032 per hour on a db.t4g.small before storage and egress, and Layerbase charges a flat monthly plan price with no hourly meter at all.

Can I run MariaDB locally the same way?

Yes, and it is the same binary. lbase create maria1 -e mariadb --start downloads the upstream mariadbd for your platform and runs it as a managed process, with no Docker and no brew services ritual. Standard MySQL clients connect to it because MariaDB ships the same wire protocol. The pattern that works well is the Layerbase CLI locally and Layerbase Cloud for staging and production, so behaviour matches in both places.

Should I use MariaDB or MySQL?

For ordinary CRUD against indexed tables with foreign keys they are still effectively drop-in compatible, so it rarely matters. Pick MariaDB if you want SEQUENCE, system-versioned tables, ColumnStore, or the JSON path improvements; pick MySQL if you need the CLONE plugin, the INSTANT ALTER TABLE algorithm, or you are betting on Oracle's HeatWave direction. Layerbase Cloud runs both, so you can try one without committing your hosting to it.

Why does MariaDB on Layerbase use a dedicated port instead of SNI?

Because MySQL and MariaDB share a server-speaks-first protocol that does not expose a hostname during the TLS handshake, so there is nothing for us to route on. Postgres and friends get SNI routing; MariaDB gets a dedicated TLS port per instance instead. The port shows up in your connection string and the certificate is valid for the database hostname, so nothing about your client setup changes.

Where to start

If you want a deeper walkthrough of MariaDB itself, the getting started guide covers the engine in more detail with a working TypeScript example. If you already have a database to move, the Layerbase Cloud create flow will pull it across from a connection string.