Comparing databases for Vercel and Netlify
Vercel and Netlify make it easy for developers to build and ship full-stack serverless applications. Both platforms provide features such as serverless edge functions, CDN (content delivery network), build tools, analytics, etc. While building full-stack applications on these platforms, developers have quite a few options for their data layer (database). This article compares the databases commonly used with Vercel and Netlify, so you can make an informed decision when picking a new database for your project.
PlanetScale
PlanetScale is an easy to use MySQL-compatible serverless database. MySQL is easy to get up and running. However, you have to scale up your MySQL instances as your database grows. Database sharding is a common technique that is used to scale MySQL.
Sharding is a scale-out technique in which database tables are partitioned and each partition is hosted on its own RDBMS server. In the case of MySQL, this means that each node is its own MySQL RDBMS, with its own set of data partitions.
PlanetScale uses Vitess sharding to scale up the databases. While Vitess makes it easier to administer database shards, PlanetScale doesn’t actually shard databases automatically, so this is something that needs to be engineered on your own. If you wish to scale your database in a distributed manner – either now or in the future – you need to take this limitation into consideration.
Shards can be complicated to get right. You occasionally have to worry about splitting bits which is complicated. Joins across shards are not easily doable. If you need cross-shard joining, you probably need a data warehouse.
At the moment, PlanetScale appears to provide limited functionality and has focused its key differentiator around its unique branching feature for schema migration. However, some core database features seem to be missing, such as support for foreign key constraints.
PlanetScale with edge architecture
One of the primary appeals of Vercel and Netlify is that they have serverless edge support. Edge offering allows you to keep your serverless functions closer to your users.
For instance, let's assume you have a Next.js application deployed on Vercel. A user from Spain tries to access your application. The application will then be served from the nearest location to Spain. Vercel distributes your application worldwide, so your users don't face the added latency.
However, if your database is not distributed, then your edge functions will not be as performant. For instance, if your database server is located in New York, USA, and your compute function is in Lisbon, Portugal, it will add a significant delay. Ideally, you need a database that is also distributed globally to reduce latency.
To learn more about edge vs serverless performance and what role databases play in the architecture refer to this video.
Since PlanetScale is not globally distributed, it might have some performance drawbacks. However, PlanetScale does offer multiple regions, and you can manually architect your application to fetch data from the nearest region.
If you are building an application that requires very low latency and strong consistency across multiple regions, PlanetScale might not be a solid choice.
Pros | Cons |
---|---|
MySQL compatible (easy for MySQL users) | Not a distributed database |
Scales horizontally using Vitess sharding | Doesn’t shard automatically |
Branching mechanism | No foreign key constraints |
Relational data modeling | No realtime API |
MongoDB (MongoDB Atlas)
Another popular choice is MongoDB. MongoDB is a NoSQL database with optional schemas. MongoDB is flexible and suitable for both structured and unstructured data. Mongo Atlas provides managed instances of the Mongo database. Mongo saves data in JSON format.
Assessing the performance of two different database systems is very difficult since both systems approach the task of data storage and retrieval in entirely different ways. MongoDB is also optimized for write performance. Due to its document-oriented nature and prioritizing speed over transaction safety, MongoDB usually outperforms traditional relational databases.
Unlike a relational database, MongoDB doesn’t support foreign key joins. Because of this modeling your data relationships can be tricky with Mongo. There are other ways to get around this problem in MongoDB. Review this thread to learn more about data modeling in MongoDB.
You create indexes in MongoDB to execute queries and access data efficiently. Without indexes, you must perform a collection scan in MongoDB. If your indexing is incorrectly implemented or has any discrepancies or other errors, it negatively impacts the speed and performance of MongoDB.
MongoDB Atlas supports GraphQL. You can also use change streams to implement real time functionality.
One limitation MongoDB is that it is not transactional. If your application requires transactional data MongoDB might not be the right fit. Incorrect or complex indexing coupled with lack of structured relationship can lead to data corruption in MongoDB if not careful.
MongoDB Atlas with edge architecture
MongoDB Atlas offers serverless instances of MongoDB; however this is not distributed. Meanwhile, the managed service (provisioned) Atlas offering supports global replication of your data out of the box.
If you want to use your edge architecture to its full potential, you have to replicate data manually and have your database servers located close to your edge servers. Again this can be challenging.
The provisioned version of MongoDB Atlas also requires TCP/IP to connect with edge functions, which is incongruent with edge/serverless functions that are ephemeral in nature (as you’ll have to maintain connection pools with MongoDB even when the function isn’t being called).
If your application doesn't require a transactional database, out-of-the-box multi-region replication mechanism, and you don’t require complex RDBMS like data modeling, then go with MongoDB.
Pros | Cons |
---|---|
Flexible, easy to use query expression | Need to manage connection pooling |
Reliable and easy to scale | Performance costs with distributed transactions |
GraphQL support through MongoDB Atlas | Mongo has a hard limit of 16MB per document |
More performant than any relational database | Atlas is (or can be) globally distributed, but you need to manage clusters and shard keys |
Fauna
Fauna is a distributed document-relational database delivered as a cloud API. Fauna combines the best of both SQL and NoSQL. With Fauna, you get the flexibility of a NoSQL database and a SQL database's relational data modeling capabilities.
Fauna also has user-defined functions (UDFs) features which allow you to compute on your data and reduce the round trip to your database. Learn more about Fauna’s UDFs here.
You also have the capability to build real-time applications with Fauna's streams API.
At its core, Fauna uses a proprietary query language called FQL (Fauna Query Language).
Fauna is natively integrated with Vercel and Netlify
These integrations make it easy to use Fauna as the database for your sites and functions.
Fauna and edge architectures
Fauna was built for modern applications. It requires zero configuration and management. Fauna is strongly consistent, serverless, and globally distributed. And because Fauna is globally distributed, your data is automatically replicated and placed closest to your edge servers.
Fauna is designed to take full advantage of the edge architecture and ensures that your users get the data from the nearest location. Fauna can be accessed through an HTTP call, and unlike MongoDB and some other NoSQL databases, it doesn’t directly rely on underlying TCP/IP for connection.
If you want the flexibility and performance of NoSQL with the reliability, data modeling, and strong consistency of SQL, then Fauna is the appropriate database for you.
Fauna's flexible document-relational data modeling (as it combines the best of SQL and NoSQL) makes it a smooth developer experience. Developers also have the option to choose a driver to query their database, which in turn makes developers more productive.
When you build on platforms like Netlify or Vercel, you focus on your code and delivering features fast without thinking about the servers, latency, or scaling up; these platforms take care of everything. Fauna follows the same philosophy. You spin up your database, connect your application, and everything else (i.e., scaling up, global distribution of data, region groups, replication) is taken care of by Fauna.
Pros | Cons |
---|---|
Document-relational database (Combines the flexibility and performance of NoSQL with the reliability of SQL) | Fauna Query Language is new and requires some time to get used to |
Serverless and distributed | |
Auto scales (Pay per usage) | |
Allows compute on data with UDFs | |
Strong consistency | |
Real time API support with streams |
Final words
Platforms like Vercel and Netlify enable developers to quickly build applications and solutions while simultaneously improving the developer experience. These platforms abstract away server management, scaling, and infrastructure so you and your engineering team can focus on shipping features and writing code. The data layer is critical in developing, launching, and scaling a successful product, so why not choose a database that is also built with the philosophy of serverless edge architecture? You can signup for a free instance (no credit card required) of Fauna here and start building today. I hope this article helps you make an informed decision on your choice of a database while building with Vercel or Netlify.
If you enjoyed our blog, and want to work on systems and challenges related to globally distributed systems, and serverless databases, Fauna is hiring
Subscribe to Fauna's newsletter
Get latest blog posts, development tips & tricks, and latest learning material delivered right to your inbox.