The term “serverless database” has gained popularity with the rise of cloud computing and on-demand services, but it has a dual meaning depending on context.

In particular, databases can be “serverless” in either the traditional, client-side manner (e.g., SQLite’s model) or the cloud-native way often associated with managed databases.

This article explores these two approaches to serverless databases—classic serverless and neo-serverless—along with contrasting examples from other database models like client/server architectures.

What is a Serverless Database?

In broad terms, a serverless database is a database system that abstracts away the need for a dedicated server for database operations. This can manifest in two ways (as described in the SQLite documentation):

• Classic Serverless: The database operates on the client-side without a server instance, as seen in SQLite.
• Neo-Serverless: The database is hosted on the cloud, with automatic scaling, managed services, and pay-per-use billing.

Let’s examine these two types of serverless databases, their characteristics, and some examples.

Classic Serverless Databases

The classic serverless approach to databases means the database runs entirely on the client-side, with no centralized server to manage or connect to. The application accesses the database directly, without an intermediary server process, making this model suitable for applications where simplicity, portability, and local storage are prioritized.

Characteristics of Classic Serverless Databases

• Embedded in Applications: The database runs as part of the application, allowing data to be stored and retrieved directly from the client device.
• No Dedicated Server Process: Unlike traditional client/server databases, classic serverless databases do not rely on a server or daemon process.
• Lightweight and Self-Contained: Classic serverless databases are designed to be lightweight, often distributed as a single-file library that can easily be embedded into applications.

Example: SQLite

SQLite is probably the best example of a classic serverless database. It’s a self-contained, zero-configuration database engine often embedded in applications ranging from mobile apps to web browsers. SQLite’s architecture allows the database file to be read and written directly by the client application without needing a server process, which is why it’s commonly used in scenarios where:

• Applications require local data storage, like mobile applications.
• No network connectivity is available.
• The need for complex data processing or transaction throughput is limited.

For example, Android and iOS both use SQLite as the embedded database in their application development kits because it is portable, fast, and simple to use without needing a network connection or a database administrator.

Neo-Serverless Databases

The neo-serverless model, commonly associated with cloud-native databases, aims to provide a serverless experience in a hosted environment. This model abstracts the underlying infrastructure, allowing developers to interact with the database without managing servers, configurations, or scaling requirements.

Neo-serverless databases are typically hosted in the cloud and managed by providers who handle provisioning, scaling, security, and failover.

So neo-serverless databases are not actually serverless. There is a server, but it’s hidden from the developer.

Characteristics of Neo-Serverless Databases

• Fully Managed Service: Database provisioning, scaling, and maintenance are managed by the cloud provider, allowing developers to focus solely on application logic.
• On-Demand Scaling: These databases automatically scale based on usage, supporting high traffic and variable workloads.
• Pay-as-You-Go: Users are charged based on actual consumption rather than fixed pricing, which makes it cost-effective for applications with sporadic or unpredictable workloads.
• Multi-Region and High Availability: Cloud providers often distribute neo-serverless databases across multiple regions, offering built-in replication and high availability.

Examples of Neo-Serverless Databases

Several databases exemplify the neo-serverless model, particularly in the cloud ecosystem:

• Amazon Aurora Serverless: Part of Amazon’s Relational Database Service (RDS), Aurora Serverless is designed to scale automatically based on demand. It can seamlessly handle spikes in traffic and charges based on actual usage, making it suitable for variable workloads and high-traffic applications.
• Google Cloud Firestore: Firestore is a NoSQL document database optimized for mobile and web applications. It offers seamless synchronization across devices and autoscaling features, and charges based on operations, storage, and data transfer.
• Azure Cosmos DB: Microsoft’s Cosmos DB is a globally distributed, multi-model database service that automatically scales throughput and storage based on demand. It offers multiple consistency models and is optimized for low-latency applications.

Other Database Models: Client/Server and Shared-Nothing Architectures

Beyond serverless models, many database management systems (DBMSs) rely on traditional architectures like client/server or shared-nothing designs, especially when high control, specific configurations, or complex data management requirements are necessary.

Client/Server Model

In the client/server model, a central database server manages database operations, with clients connecting to the server to request data. This model separates the database engine and data storage from the client applications, which is common in enterprise applications where data security, integrity, and multi-user support are priorities.

Examples of Client/Server Databases

• MySQL: A widely used open-source relational database that operates on a server, allowing multiple clients to access and modify data simultaneously.
• PostgreSQL: Known for its robustness and compliance with SQL standards, PostgreSQL operates as a client/server database with strong support for complex queries and data integrity.
• Microsoft SQL Server: Microsoft’s proprietary database system, commonly used in enterprise environments where high availability, scalability, and security are critical.

Shared-Nothing Architecture

A shared-nothing architecture distributes the database across multiple servers or nodes without shared resources, allowing each node to operate independently. This model is used by large-scale distributed databases and data warehouses.

Examples of Shared-Nothing Databases

• Apache Cassandra: A NoSQL database designed to handle massive amounts of data across multiple nodes in a distributed environment. Its shared-nothing architecture ensures fault tolerance and high availability.
• Amazon DynamoDB: An AWS-hosted NoSQL database that uses a shared-nothing architecture to deliver low-latency performance for web applications requiring real-time data access.

Comparing Classic Serverless, Neo-Serverless, and Other Models

Let’s condense the aforementioned database models into a table to make it easier to compare:

Model	Characteristics	Examples
Classic Serverless	Client-side, embedded in applications, no server process, single-file	SQLite
Neo-Serverless	Cloud-hosted, fully managed, on-demand scaling, pay-as-you-go	Amazon Aurora Serverless, Firestore, Azure Cosmos DB
Client/Server	Centralized server, multiple client connections, secure, scalable	MySQL, PostgreSQL, SQL Server
Shared-Nothing	Distributed nodes, no shared resources, high fault tolerance	Cassandra, DynamoDB

Some Databases Have Multiple Deployment Models

It’s becoming increasingly common for DBMSs to offer different deployment models to cater to a variety of use cases and infrastructure requirements. These range from traditional client/server architectures to serverless and distributed cloud versions.

For example, although PostgreSQL’s primary model is the client/server setup, there’s also a serverless option called Neon that provides on-demand scaling and simplified management, optimized for the cloud.

Choosing the Right Model

Selecting the appropriate database model depends on several factors:

• Application Requirements: For simple applications needing local storage, classic serverless databases like SQLite are effective. For cloud-native applications requiring autoscaling and multi-region support, neo-serverless databases are more suitable.
• Data Volume and Throughput: Applications with high throughput and large data volumes may benefit from shared-nothing databases, while enterprise applications with complex queries and multi-user access may prefer a client/server setup.
• Infrastructure and Budget: Neo-serverless databases allow budget-conscious scaling based on demand, whereas client/server models may incur more consistent, infrastructure-heavy costs.

Conclusion

If someone makes reference to a serverless database, be sure that you understand what they actually mean. With cloud computing becoming more and more popular, it’s likely that they mean serverless in the neo-serverless sense of the word (i.e., a cloud database). But if they’re referring to a database implementation like SQLite, then they’re probably using the classic serverless definition.