LayerbaseLayerbase

SkySQL alternatives: serverless MariaDB hosting in 2026

MariaDBMySQLDatabases

MariaDB Corporation discontinued their own SkySQL DBaaS in 2023. The product got spun out as a separate company under a similar name, then quietly faded from most people's awareness. The result is that searching for "managed MariaDB" today returns mostly AWS RDS MariaDB, Aurora, and Azure Database for MariaDB. All of those are real options, but none of them are serverless in the way the modern Postgres world has come to expect.

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, briefly

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. It shut down in its original form in 2023. The brand name lives on at a different entity that focuses on MariaDB-compatible distributed SQL, but it's a different product targeting a different market.

The practical effect: the canonical "I just want managed MariaDB" answer became "use AWS RDS." 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 AWS account just for the database.

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.

bash
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:

text
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 SpinDB

For local development, 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 SpinDB?)

bash
npm i -g spindb        # npm
pnpm add -g spindb     # pnpm

Create an instance:

bash
spindb create maria1 -e mariadb --start

Get the connection URL:

bash
spindb url maria1
text
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.

bash
spindb stop maria1
spindb start maria1
spindb list

The pattern that works well: SpinDB 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 Mac 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: AWS RDS, Aurora, or 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 Database for MariaDB is the Azure equivalent.

The reasons to pick one of these:

  • You're already deep in AWS or Azure 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 minimum useful instance size starts around $30 to $50 a month, which is a lot for a side project.
  • 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.

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 5: 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? SpinDB.
  • Prefer a Mac app? Layerbase Desktop.
  • Already on AWS or Azure and need production-scale HA? RDS or the equivalent.
  • 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 thing that needed solving was the missing serverless on-ramp after SkySQL went away, and that's what Layerbase Cloud is filling.

If you want a deeper walkthrough of MariaDB itself, the getting started guide covers the engine in more detail with a working TypeScript example.

Something not working?