The term “serverless” has been applied to functions, APIs, and now databases. As with its predecessors, it does not mean there are no servers; it simply means that you don't have to think about them. That's because serverless databases handle provisioning, scaling, and capacity planning automatically, letting developers focus on building rather than babysitting infrastructure. For teams used to sizing RDS instances and manually adjusting read replicas, the shift can feel significant. This article explains how serverless databases work, surveys the major offerings, and looks at how Navicat fits into the picture.
What Makes a Database “Serverless”?
The defining characteristic of a serverless database is the separation of storage and compute. In a traditional database deployment, the two are tightly coupled: your instance has a fixed amount of CPU, memory, and disk, and you scale by upgrading the instance. In a serverless architecture, storage is decoupled from the compute layer, which means each can scale independently. Compute can ramp up to handle a traffic spike and then scale back down (or even to zero during idle periods) while the data remains intact and available.
This model has two practical implications for developers. First, you pay for what you actually use rather than reserving capacity you might need at peak. Second, you stop worrying about whether your instance is correctly sized, because the database adjusts itself.
Amazon Aurora Serverless
Aurora Serverless v2 is Amazon's on-demand, auto-scaling configuration for Aurora, available in both MySQL-compatible and PostgreSQL-compatible editions. It scales in fine-grained increments - as small as 0.5 Aurora Capacity Units (ACUs) - and can scale across a wide range without disrupting active connections or transactions. Unlike the original Aurora Serverless v1, which had notable cold-start latency issues, v2 scales much more fluidly and supports the full breadth of Aurora features including Multi-AZ deployments, global databases, and read replicas.
Aurora Serverless v2 is a strong choice for applications with unpredictable or highly variable workloads such as development and staging environments, event-driven applications, or any system where demand spikes sharply and infrequently. Its deep integration with the AWS ecosystem makes it a natural fit for teams already running infrastructure on AWS.
Neon
Neon is an open-source serverless PostgreSQL platform built around what it calls a “lakebase” architecture: storage and compute are fully decoupled, with data persisted to cloud object storage and compute nodes that can scale to zero when idle. When a new query arrives, compute spins up in seconds and attaches to the existing data history without any data movement.
One of Neon's most developer-friendly features is database branching. Similar to a Git branch, a Neon branch creates an isolated copy of your database at a specific point in time using copy-on-write semantics, No data is duplicated, so branches are instantaneous and cheap. This makes it straightforward to spin up a branch for a feature, run migrations against it, and discard it when done, without ever touching production. Neon has become a popular choice for teams building on PostgreSQL who want cloud-native agility without leaving the PostgreSQL ecosystem behind.
PlanetScale
PlanetScale originally built its reputation on bringing MySQL into the serverless era, powered by Vitess - the same database clustering technology that handles YouTube's traffic. Its standout contribution to developer workflow is database branching with non-blocking schema changes: instead of running an ALTER TABLE directly on production and holding your breath, you create a branch, make the schema change, open a deploy request, and merge when ready.
The platform has evolved significantly in recent years. PlanetScale retired its free Hobby tier in 2024 and has since pivoted toward enterprise customers, with paid plans starting at $39 per month. It has also expanded beyond MySQL, launching a managed sharded PostgreSQL service built on local NVMe storage. PlanetScale is now firmly positioned as a high-performance, high-scale platform for teams with serious throughput requirements rather than a free tier for hobbyists.
Other Notable Offerings
The serverless database landscape extends well beyond these three.
- Supabase layers a full backend platform on top of PostgreSQL, adding authentication, storage, and real-time subscriptions alongside serverless database hosting.
- CockroachDB Serverless offers distributed SQL with automatic sharding across regions.
- Turso, built on libSQL (a fork of SQLite), targets edge deployments with per-database tenancy at very low latency.
Each reflects a different point on the spectrum between simplicity and power.
Connecting to Serverless Databases with Navicat
One practical challenge with serverless databases is that the tools developers already use need to keep working. Fortunately, most serverless databases deliberately maintain full wire-protocol compatibility with their underlying engines, which means any client that can connect to MySQL or PostgreSQL can connect to them - and that includes Navicat.
Navicat Premium supports connections to Amazon Aurora directly through its built-in Amazon AWS connection type, where you can configure an Aurora connection and benefit from the same full-featured environment - query editor, data viewer, schema management, data transfer - that you would use with a traditional MySQL or PostgreSQL instance. For Neon and PlanetScale, connections are established using Navicat's standard PostgreSQL and MySQL connection types respectively. Both platforms provide a standard connection string from their dashboards; you enter the host, port, database name, and credentials into Navicat's connection dialog, enable SSL as required, and connect.
This means the workflow serverless databases are designed to enable - rapid iteration, branching, safe schema changes - can be paired with Navicat's tools for query analysis, visual explain, data synchronization, and schema comparison. You get the operational simplicity of serverless infrastructure without giving up the depth of a professional database management environment.
Some Caveats to Be Aware Of
Serverless databases are not universally superior to provisioned ones. Cold starts remain a real consideration for latency-sensitive applications, even if the problem has improved significantly with newer platforms. Connection handling can also behave differently - because compute can scale to zero and back, connection pooling is more important than ever; most platforms include it natively, but it is worth understanding how your chosen platform manages connections before going to production. Finally, pricing based on consumption can be harder to predict than a fixed monthly instance cost, particularly for applications with consistent high-volume workloads where provisioned databases may actually be more cost-effective.
Conclusion
Serverless databases have matured considerably and are now a credible choice for a wide range of production workloads, not just development environments. Aurora Serverless v2, Neon, and PlanetScale each represent a distinct take on the model, and the right choice depends on your engine preference, scale requirements, and workflow priorities. What they share is the ability to reduce operational overhead significantly. Moreover, because all of them maintain standard MySQL or PostgreSQL compatibility, connecting and managing them through Navicat requires no special configuration or compromise in capability.
