Some people love debating technology choices like sports teams. What's your favorite framework or database? Who you got?

My formative experience with databases is that they were the most annoying part of WordPress development—which shaped the majority of my career as a developer.

Being responsible for the uptime, maintenance, backup, and migration of a MySQL database is something I never wanted to do again. It's busywork and too much of a distraction from solving customer problems.

When I first used Sanity (years before joining) the promise was instantly obvious. I could just focus on the good parts of building out a content management system—customizing the admin dashboard—and all of the worst, annoying, and brittle parts—handling a database—were abstracted away. I was instantly won over.

A lot of technologies which Sanity have made are open source or open standards. The GROQ query language, the Portable Text Specification, and the editor. We put these things out there because we want others to use and adopt them.

But there's this one part—The Content Lake—that forms the secret source of the entire Content Operating System. It does way too much to be abstracted away into generics. It's more than just a database. It's a database optimized for content. It handles real-time data. It handles multiplayer editing. It provides a CDN for content queries and assets. It handles reactive processes invoked by changes.

Essentially, the content backend that Sanity provides does too much for it to be hot-swapped between individual user's favorite flavor of database.

This is why I wanted to have Simen on the podcast to discuss this part of the platform, why we closed off the backend and the benefits that it provides.

(I’m playing Devil's Advocate on this episode. Of course, we're both on the same team!)

In many parts of application development, you get to make your own choices and choose generic tools. Content Lake is a specialized tool with a specific purpose—a database optimized for content. Compatible with any framework. If you'd rather build content-backed applications that solve problems, than maintain a database, there's no better choice.

So, while choosing your own self-hosted database is fine for many applications, we firmly believe that our solution is better for content editing, storage, and delivery. Some may see this as a negative in terms of choice, but I see it as a positive in terms of my time.