Cloudflare announces their first DATABASE!! To my surprise, it is a SQL database.
I was fully expecting a document database akin to MongoDB. However, it is a SQL database utilizing SQLite, an open source SQL based database. This is a HUUUUUGE development in many ways.
- SQL databases are by far the most commonly used and the SQL language is probably the most known in the world.
- Allows for complete applications built within the Cloudflare design
One thing to note, it is NOT a multi-write database. MongoDB is a multi-write. This is much more like the SOCRATES architecture used by Azure SQL Database HYPERSCALE & AWS AuroraDB. It does provide MULTI-READ and even better, in a SERVERLESS manner.
FF, what is the potential issue with single-write? BANDWIDTH; performance, time.
Let me paint a picture.
Saul’s SaaSSY is a new SaaS product that helps companies with accounting “stuff”. They are doing business in the US, Canada, EU… around the world. They are built in this NEW Cloudflare database. The database is in Chicago.
FF corporation is in Germany and uses Saul’s SaaSY. FF’s accounting department has people in Germany and Australia. When FF Corp in Germany logs in, Cloudflare creates a SERVERLESS READ ONLY copy of the data in Germany. Similarly, when FF Corp Australia logs in, Cloudflare creates a READ ONLY copy in Australia. Note, after an hour or so of not using this copy, the SERVERLESS and copy are deallocated.
Now, FF Germany finds an error in an address and updates the address. They use the READ ONLY copy to come up with the transaction to write. They submit the transaction. That transaction has to travel to Chicago then to ensure data consistency, the READ ONLY replicas need to be updated as fast as possible so that everyone is looking at the most recent set of data. It would be pretty bad if FF Germany sent the transaction and at almost the same time, FF Australia went in and noticed the error and typo’d a new address and submitted that before seeing that it was already updated by FF Germany… So it is very important to be able to prevent this kind of issue. So the time and performance and internal mechanisms of the database to prevent this type of issue are very important. It is vital that the speed of the write and the speed to update the read-only copies are very very fast (as well as other internal things done to ensure consistency). If it is slow, this can cause big issues.
The biggest advantages I see for NET here is that the serverless read only replicas can be in any of their PoPs where-as the read only replicas for Hyperscale or AuroroaDB are specified. Also, the pricing looks to be a whole lot cheaper than AuroraDB and Hyperscale. These databases charge a very high premium.