Adds a doc on shared responsibility

apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts

@@ -932,9 +932,15 @@ export const platform = {
       ],
     },
     {
-      name: 'Go-live Checklist',
+      name: 'Production Readiness',
       url: undefined,
-      items: [{ name: 'Production Readiness', url: '/guides/platform/going-into-prod' }],
+      items: [
+        {
+          name: 'Shared Responsibility Model',
+          url: '/guides/platform/shared-responsibility-model',
+        },
+        { name: 'Go-live Checklist', url: '/guides/platform/going-into-prod' },
+      ],
     },
     {
       name: 'Troubleshooting',

apps/docs/pages/guides/platform/shared-responsibilty-model.mdx

@@ -0,0 +1,49 @@
+import Layout from '~/layouts/DefaultGuideLayout'
+
+export const meta = {
+  id: 'shared-responsibility-model',
+  title: 'Shared Responsibility Model',
+  description: 'Running databases is a shared responsibility between you and Supabase.',
+}
+
+Running databases is a shared responsibility between you and Supabase. There are some things that we can take care of for you, and some things that you are responsible for. This is by design: we to give you the freedom to use your database however you want. While we _could_ put many more restrictions in place to ensure that you can’t do anything wrong, you will eventually find those restrictions prohibitive.
+
+Generally, we aim reduce your burden of managing infrastructure and knowing about Postgres internals, minimizing configuration as much as we can. Here are a few things that you should know:
+
+## You share the security responsibility
+
+We give you full access to the database. If you share that access with other people (either people on your team, or the public in general) then it is your responsibility to ensure that the access levels you provide are correctly managed.
+
+If you have an inexperienced member on your team, then you probably shouldn’t give them access to Production. You should set internal workflows around what they should and should not be able to do, with restricted access to avoid anything that might be deemed dangerous.
+
+You are also responsible for ensuring that tables with sensitive data has the right level of access. You are also responsible for managing your database secrets and API keys, storing them safely in an encrypted store.
+
+## You can crash your database
+
+”Crash” is used liberally here. It refers to any situation where your application is unable to work as desired because of DB issues. It could be because the DB is unable to support the number of connections being attempted, or because its performance is unacceptably low because of CPU or memory constraints.
+
+You are responsible of provisioning enough compute to run the workload that your application requires. You are also responsible for employing methods to manage the workload: adding indexes, adding filters on large queries, caching strategies, materialized views, etc.
+
+## You decide your own workflow
+
+There are _many_ ways to work with Supabase.
+
+You can use our Dashboard, our CLI, external tools like Prisma and Drizzle, or migration tools like Flyway and Sqitch. You can develop directly on your database, run migrations from [local to production](/docs/guides/getting-started/local-development), or you can use [multiple environments](/docs/guides/cli/managing-environments).
+
+None of these are right or wrong. It depends on the stage of your project. You _definitely_ shouldn’t be developing on your database directly when you’re in production - but that’s absolutely fine when you’re getting started and don’t have users.
+
+## You are responsible for your application architecture
+
+Supabase is not a silver-bullet that will solve bad architecture decisions. A poorly designed database will run poorly, no matter where it’s hosted.
+
+You can get away with a poorly-designed database for a while by simply adding compute. After a while, things will start to break. The database schema is probably the area you want to spend _the most_ time thinking about. That’s the benefit of Supabase - you can spend more time designing a scalable database system and less time thinking about the mundane tasks like implementing CRUD APIs.
+
+If you don’t want to implement logic inside your database, that 100% fine. You can use _any_ tools which work with Postgres.
+
+## You choose your level of comfort with Postgres
+
+Our goal at Supabase is to make _all_ of Postgres easy to use. That doesn’t mean you have to use all of it. If you’re a Postgres veteran, you’ll probably love the tools that we offer. If you’ve never used Postgres before, then start smaller and grow into it. If you just want to treat Postgres like a simple table-store, that’s perfectly fine.
+
+export const Page = ({ children }) => <Layout meta={meta} children={children} />
+
+export default Page