The serverless tech space is changing, offering new opportunities in the database architecture scene. Today, we’re zooming in on three serverless databases - Fauna, PlanetScaleDB, and NeonDB - each with its unique strengths and features.
Fauna is a globally distributed NoSQL database, known for its consistently low latency times, strong consistency profile, and relational capabilities within the context of a flexible document-oriented data model. Its pay-as-you-go model means you’re only charged for actual usage - no costs during idle times. Plus, developers appreciate Fauna’s robust Fauna Query Language and its wide support for various languages.
For those in the SQL realm, PlanetScaleDB offers a great solution. This database is designed to manage and scale MySQL databases, providing high-performance reads and writes. Like Fauna, PlanetScaleDB also follows a usage-based model, so you only pay for the resources you consume.
NeonDB is built for real-time, high-performance applications. This PostgreSQL-based relational database stands out with its high-speed read and write operations. NeonDB follows a consumption-based model, charging customers only for the data they use.
TL;DR: Comparing Fauna, PlanetScaleDB, and NeonDB
|Database||DB Type||Free Tier Offering, Pricing Model||Region Support||Distinct Feature Offering|
|PlanetScaleDB||SQL (MySQL-based)||Free tier: 10GB storage, 20 connections. Developer plan: $49/month, 10 databases, 20GB storage, 100 connections. Business plan: $999/month, 25 databases, 100GB storage, 500 connections||Global: East Asia, Europe, North America, South Asia, Australia||Branching, Non-blocking schema changes, Deploy schemas from CI/CD, Automated failover|
|NeonDB||SQL (PostgreSQL-based)||Free tier: Up to 1 million requests per day, 10GB storage. Pricing scales with usage, with additional costs for data transfer, backups, and replication||North Virginia, Oregon, Frankfurt, Ireland, Sydney, Mumbai, São Paulo, London||Database Branching, Fully Serverless, Multi-Cloud and Multi-Region, Fine-Grained Security with PostgreSQL RLS|
So we decided to see how fast our three chosen databases could go. We set up a test, and crunched the numbers with the following parameters:
- Compute: We ran the tests on AWS Lambda with its default configurations in the same region as the databases were set up (us-east-1/US North Virginia) and used API Gateway to invoke it.
- Schema: We created the same database schema in each service and populated them with identical volumes of data.
- Querying: We used the native drivers provided by each service to query the databases. We ran the tests for various row limits, specifically 10, 50, 100, 250, 500, 1000, 2500, and 5000 rows.
- Repetition and Averaging: Each data size query was performed multiple times for each database. This was done to account for any inconsistencies and to establish an average response time.
Note that these numbers are excluding Lambda Cold Starts but could include Cold Starts from the Database Provider itself.
|Database||Rows: 10||Rows: 50||Rows: 100||Rows: 250||Rows: 500||Rows: 1000||Rows: 2500||Rows: 5000|
|Fauna||49.9 ms||53.1 ms||45.9 ms||86.2 ms||147.2 ms||280.1 ms||705.9 ms||1293.5 ms|
|Neon||56.4 ms||18.7 ms||20.8 ms||44.5 ms||56.4 ms||107.4 ms||160.7 ms||304.6 ms|
|PlanetScale||149 ms||55.3 ms||14.5 ms||47.1 ms||74.5 ms||142.8 ms||344.1 ms||836.9 ms|