Strapi를 벗어났을 때: Payload + Supabase로 구축하기

지난 몇 년간 나는 적어도 dozen 개의 클라이언트 프로젝트를 위해 Strapi를 설정했습니다. 시작하기에 좋은 CMS입니다 -- 친화적인 관리 패널, 괜찮은 플러그인 생태계, 견고한 문서. 하지만 대략 18개월 지점에서 내가 함께 일한 거의 모든 팀이 한계에 도달합니다. 마이그레이션은 고통스러워지고, 커스터마이제이션은 임시방편 같아지고, TypeScript를 사랑하는 프론트엔드 개발자들은 개발자 경험에 대해 투덜거리기 시작합니다. 익숙한 상황이라면 당신 혼자가 아닙니다. 당신이 Strapi를 벗어났다는 신호들과 더 중요하게는 대신 무엇을 구축할지 안내해드리겠습니다.

목차

• 초기 단계: Strapi가 초기에 작동하는 이유
• Strapi를 벗어났다는 6가지 신호
• 옵션 이해하기: Payload vs Supabase vs 현상 유지
• Payload CMS가 자연스러운 다음 단계인 이유
• Supabase가 어디에 적합한지 (그리고 어디에 적합하지 않은지)
• Payload + Supabase 스택: 아키텍처 심화
• 마이그레이션 전략: Strapi에서 벗어나기
• 성능 벤치마크 및 실제 숫자
• 이 스택이 올바른 선택이 아닐 때
• FAQ

초기 단계: Strapi가 초기에 작동하는 이유

공정하게 평가해봅시다. Strapi가 GitHub에서 65K+ 스타를 받은 이유가 있습니다. 새로운 콘텐츠 중심 프로젝트를 시작할 때, Content-Type Builder는 정말 유용합니다. GUI를 클릭하고 몇 가지 필드를 정의하면 -- REST와 GraphQL API가 나옵니다. 비기술적 콘텐츠 편집자들은 관리 패널에 로그인하여 한 시간 내에 발행을 시작할 수 있습니다.

초기 단계 스타트업, 마케팅 사이트, 블로그의 경우 Strapi는 완전히 합리적인 선택입니다. PostgreSQL, MySQL, MariaDB, SQLite를 지원합니다. 플러그인 마켓플레이스에는 100개 이상의 커뮤니티 확장이 있습니다. 커뮤니티 에디션은 MIT 라이선스로 무료입니다.

나는 Strapi를 여러 번 추천했습니다. 나는 여기서 그것을 공격하려는 것이 아닙니다. 다음에 어떤 일이 일어나는지 이야기하려는 것입니다.

Strapi를 벗어났다는 6가지 신호

이것들은 내가 반복적으로 보는 패턴입니다. 이 중 3개 이상이 공감된다면, 마이그레이션을 계획할 시간입니다.

1. 마이그레이션이 당신을 불안하게 만든다

v4에서 v5로의 업그레이드는 많은 팀을 깨뜨린 것입니다. Strapi는 50개 이상의 주요 변경 사항을 문서화했습니다. 실제로 중간 복잡도의 프로젝트의 경우 마이그레이션에 40시간 이상의 개발자 시간이 걸리는 것을 봤습니다. 그것은 마이너 버전 범프가 아닙니다 -- 콘텐츠 레이어의 재작성입니다.

다음 메이저 버전이 사용자 정의 컨트롤러의 절반을 깨뜨릴 것을 알고 있어서 우려된다면, 당신은 이 도구를 벗어났습니다.

2. 개발자들이 프레임워크와 싸우고 있다

Strapi의 Content-Type Builder는 비기술적 사용자에게 훌륭합니다. TypeScript에서 살고 코드 우선 스키마를 원하는 개발자들에게는 병목입니다. GUI는 편집하지 말아야 할 파일을 생성합니다. 라이프사이클 훅은 붙어있는 것처럼 느껴집니다. TypeScript 지원은 v4 후반에 추가되었으며 여전히 기본이 아닙니다 -- 더 사후 생각입니다.

팀이 프레임워크와 함께 기능을 구축하는 대신 프레임워크를 위한 해결 방법을 구축하기 시작할 때, 그것은 명확한 신호입니다.

3. 성능이 문제가 되고 있다

Strapi의 콜드 스타트는 일반적으로 500ms에서 2000ms 범위입니다. 글로벌 지연 시간은 적극적인 캐싱 없이 200-500ms입니다. 블로그의 경우 괜찮습니다. 여러 지역의 사용자를 제공하는 전자 상거래 플랫폼의 경우 아닙니다.

Strapi에서 다국어 제품 카탈로그를 실행하는 클라이언트가 있었습니다. ~50,000개의 콘텐츠 항목을 깊은 관계로 넘기면 API 응답 시간이 2초 이상으로 증가했습니다. 어떤 인덱싱도 그것을 고치지 못했습니다.

4. 유료 계층 뒤에 잠긴 기능이 필요하다

Strapi의 Growth 플랜은 월 $45이고 3개의 좌석을 포함합니다 (추가 좌석은 각각 $15). 이것은 AI 기능, 라이브 미리보기, 콘텐츠 기록을 잠금 해제합니다. Enterprise 가격은 맞춤형입니다.

문제는 가격이 아닙니다 -- 원칙입니다. 라이브 미리보기 및 콘텐츠 버전 관리 같은 기능은 2025년 CMS에 대한 테이블 스테이크처럼 느껴집니다. 오픈 소스 도구에서 구독 뒤에 잠기면 개발자 팀을 화나게 합니다.

5. 스택이 Strapi의 아키텍처를 넘어 진화했다

Next.js, Vercel, TypeScript에 완전히 올인했다면 Strapi는 어색한 부록처럼 시작됩니다. 별도의 Node.js 서비스로 실행됩니다. 이는 별도의 배포, 별도의 모니터링, 별도의 스케일링 문제를 의미합니다. 프론트엔드 팀은 초 단위로 Vercel에 배포하는 동안 CMS는 자체 인프라가 필요합니다.

6. 사용자 정의 확장이 수술처럼 느껴진다

조건부 필드 논리를 추가하고 싶습니까? 검증이 있는 중첩된 반복 가능한 블록? 사용자 정의 관리 패널 구성 요소? Strapi에서 이것들은 가능하지만 고통스럽습니다. 관리 패널은 React 앱이지만 확장하는 것은 일반적인 React 개발처럼 느껴지지 않는 독점적인 확장 시스템을 탐색하는 것을 의미합니다.

옵션 이해하기: Payload vs Supabase vs 현상 유지

더 나아가기 전에, 이 도구들이 실제로 무엇인지 분명히 해봅시다. 나는 그것들이 계속 혼동되는 것을 봅니다.

도구	실제로 무엇인가	최적	좋지 않음
Strapi	관리자 GUI가 있는 오픈 소스 헤드리스 CMS	콘텐츠 편집자, 빠른 API 생성	코드 우선 팀, 고성능 앱
Payload CMS	Next.js 내부에서 실행되는 코드 우선 CMS 프레임워크	TypeScript 개발자, 사용자 정의 콘텐츠 앱	비기술적 솔로 운영자
Supabase	오픈 소스 백엔드 플랫폼 (DB, 인증, 저장소, 실시간)	애플리케이션 데이터, 인증, 파일 저장소	콘텐츠 편집 워크플로우
Directus	자동 생성 API가 있는 SQL 우선 헤드리스 CMS	기존 데이터베이스가 있는 팀	깊은 Next.js 통합
Sanity	실시간 협업이 있는 관리형 헤드리스 CMS	편집팀, 구조화된 콘텐츠	예산 의식적인 자체 호스터

Payload와 Supabase는 경쟁자가 아닙니다 -- 보완입니다. Payload는 콘텐츠 모델링, 관리자 UI, 콘텐츠 API를 처리합니다. Supabase는 데이터베이스 호스팅, 인증, 파일 저장소, 실시간 구독을 처리합니다. 함께, 그들은 Strapi를 대체하고 그 이상을 합니다.

Payload CMS가 자연스러운 다음 단계인 이유

Payload는 2025년과 2026년을 통해 진지한 파도를 만들고 있습니다. MG Software는 TypeScript/Next.js 통합에 대해 "시장 파괴자"라고 했으며, 나는 그것이 정확하다고 생각합니다.

기본적인 아키텍처 차이는 이것입니다: Payload는 Next.js 애플리케이션 내부에서 실행됩니다. 옆이 아닙니다. 별도의 서비스가 아닙니다. 내부에서. CMS와 프론트엔드는 동일한 배포, 동일한 TypeScript 타입, 동일한 빌드 프로세스를 공유합니다.

코드 우선 스키마 정의

GUI를 통해 콘텐츠 유형을 생성하는 대신 TypeScript를 작성합니다:

import { CollectionConfig } from 'payload';

export const Products: CollectionConfig = {
  slug: 'products',
  admin: {
    useAsTitle: 'name',
    defaultColumns: ['name', 'price', 'status'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'name',
      type: 'text',
      required: true,
    },
    {
      name: 'price',
      type: 'number',
      min: 0,
    },
    {
      name: 'description',
      type: 'richText',
    },
    {
      name: 'category',
      type: 'relationship',
      relationTo: 'categories',
      hasMany: false,
    },
    {
      name: 'variants',
      type: 'array',
      fields: [
        { name: 'sku', type: 'text', required: true },
        { name: 'color', type: 'select', options: ['red', 'blue', 'green'] },
        {
          name: 'stock',
          type: 'number',
          admin: {
            condition: (data, siblingData) => siblingData?.sku !== undefined,
          },
        },
      ],
    },
  ],
  hooks: {
    afterChange: [
      async ({ doc, operation }) => {
        if (operation === 'update' && doc.stock === 0) {
          // Trigger restock notification
        }
      },
    ],
  },
};

그것은 조건부 필드 논리, 중첩된 배열, 관계 필드, 역할 기반 액세스 제어, 라이프사이클 훅이 있는 실제 콘텐츠 유형입니다. 모두 한 파일에. 모두 타입 안전함. 모두 Git에서 버전 제어됨.

Strapi에서 관리자 확장 시스템과 세 가지 다른 파일에 닿지 않고 그것을 해보세요.

3개의 API 계층

Payload는 스키마에서 REST 및 GraphQL API를 자동 생성합니다. 하지만 킬러 기능은 Local API -- HTTP 오버헤드가 없는 서버 측 코드에서 직접 데이터베이스 쿼리:

// Inside a Next.js Server Component
import { getPayload } from 'payload';
import config from '@payload-config';

export default async function ProductPage({ params }) {
  const payload = await getPayload({ config });
  
  const product = await payload.findByID({
    collection: 'products',
    id: params.id,
    depth: 2, // Populate relationships 2 levels deep
  });
  
  return <ProductDetail product={product} />;
}

fetch 호출 없음. API 경로 없음. 직렬화 오버헤드 없음. 이것이 Payload가 비교 가능한 설정에서 콘텐츠 검색에서 Strapi보다 약 7배 빠르게 벤치마크되는 이유입니다.

Supabase가 어디에 적합한지 (그리고 어디에 적합하지 않은지)

Supabase는 CMS가 아닙니다. 나는 이것에 정말 명확하기를 원합니다. 그것은 PostgreSQL 위에 구축된 백엔드 플랫폼입니다. 하지만 Strapi가 잘못 처리하고 Payload가 전혀 처리하지 않는 여러 문제를 해결합니다.

Supabase가 스택에 가져오는 것

• 관리형 PostgreSQL: Payload의 PostgreSQL 어댑터는 Supabase 데이터베이스에 직접 연결됩니다. 연결 풀링, 자동 백업, 직접 SQL 쿼리를 위한 대시보드가 있습니다. Pro 플랜은 월 $25부터 시작하고 사용량에 따라 확장됩니다.
• 인증: Supabase Auth는 이메일/암호, 매직 링크, OAuth 제공자, 행 수준 보안을 지원합니다. 앱에 CMS 관리자 외에 사용자 대면 기능이 있으면, 이것은 거대합니다.
• 파일 저장소: CDN이 있는 S3 호환 객체 저장소. Payload는 미디어 업로드를 처리할 수 있지만 Supabase Storage는 애플리케이션 파일, 사용자 업로드, CMS 컨텍스트 외의 모든 것을 처리합니다.
• 실시간 구독: PostgreSQL의 LISTEN/NOTIFY는 깔끔한 WebSocket API로 래핑됨. 이것을 Payload의 라이브 미리보기와 쌍으로 하여 실시간 콘텐츠 편집 경험을 얻습니다.
• Edge Functions: 웹훅 핸들러, 백그라운드 작업, 통합을 위한 Deno 기반 서버리스 함수.

Supabase가 하지 않는 것

콘텐츠 편집자를 위한 관리 패널을 제공하지 않습니다. 리치 텍스트 필드 및 미디어 관리가 있는 콘텐츠 API를 생성하지 않습니다. 콘텐츠 로컬라이제이션이나 버전 기록을 처리하지 않습니다. 그것이 Payload의 일입니다.

Payload + Supabase 스택: 아키텍처 심화

Strapi에서 마이그레이션하는 팀을 위해 이것을 설정하는 방법입니다. 이것은 콘텐츠 관리가 핵심 요구사항인 Next.js 개발 프로젝트에 대해 일반적으로 권장하는 아키텍처입니다.

프로젝트 구조

├── src/
│   ├── app/                    # Next.js App Router
│   │   ├── (frontend)/         # Public-facing pages
│   │   └── (payload)/          # CMS admin routes (auto-generated)
│   ├── collections/            # Payload collection configs
│   │   ├── Posts.ts
│   │   ├── Products.ts
│   │   └── Users.ts
│   ├── globals/                # Payload global configs
│   │   └── SiteSettings.ts
│   ├── lib/
│   │   └── supabase.ts         # Supabase client initialization
│   └── payload.config.ts       # Main Payload config
├── supabase/
│   └── migrations/             # Supabase DB migrations
├── .env.local
└── package.json

Payload를 Supabase PostgreSQL에 연결하기

// payload.config.ts
import { buildConfig } from 'payload';
import { postgresAdapter } from '@payloadcms/db-postgres';
import { lexicalEditor } from '@payloadcms/richtext-lexical';
import { Posts } from './collections/Posts';
import { Products } from './collections/Products';

export default buildConfig({
  db: postgresAdapter({
    pool: {
      connectionString: process.env.SUPABASE_DB_URL,
      // Use Supabase's connection pooler for serverless
      max: 10,
    },
  }),
  editor: lexicalEditor(),
  collections: [Posts, Products],
  secret: process.env.PAYLOAD_SECRET,
  typescript: {
    outputFile: path.resolve(__dirname, 'payload-types.ts'),
  },
});

중요한 참고: Vercel과 같은 서버리스 환경에 배포할 때 직접 연결 URL이 아닌 Supabase의 connection pooler URL(포트 6543)을 사용합니다. 직접 연결은 로컬 개발에 잘 작동합니다.

애플리케이션 사용자를 위해 Supabase Auth 추가하기

Payload는 CMS 관리자 인증을 처리합니다. Supabase는 다른 모든 것을 처리합니다:

// lib/supabase.ts
import { createClient } from '@supabase/supabase-js';

export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

// In a Server Component or API route
import { createServerClient } from '@supabase/ssr';
import { cookies } from 'next/headers';

export async function getServerSupabase() {
  const cookieStore = await cookies();
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) =>
            cookieStore.set(name, value, options)
          );
        },
      },
    }
  );
}

이 분리는 깔끔합니다: Payload는 콘텐츠를 소유합니다. Supabase는 애플리케이션 데이터 및 사용자 신원을 소유합니다. 그들은 동일한 PostgreSQL 인스턴스를 공유하지만 각각의 영역에 머물렀습니다.

마이그레이션 전략: Strapi에서 벗어나기

설탕으로 코팅하지 않겠습니다 -- 마이그레이션은 작업이 필요합니다. 하지만 Strapi v4에서 v5로의 업그레이드보다 극적으로 덜 고통스럽습니다. 기존 정신 모델을 존중하는 시스템으로 이동하고 있기 때문입니다.

단계별 접근 방식

1. Strapi 콘텐츠 유형을 감시합니다. Content-Type Builder에서 JSON으로 내보냅니다. 각각을 Payload 수집 구성으로 매핑합니다.
2. 새로운 Next.js 프로젝트에서 Payload를 설정합니다. npx create-payload-app@latest를 실행하고 PostgreSQL 어댑터를 선택합니다.
3. Payload를 Supabase 데이터베이스로 지정합니다. 새로운 Supabase 프로젝트를 만들고, 연결 문자열을 가져오고, 어댑터를 구성합니다.
4. TypeScript에서 스키마를 다시 만듭니다. 이것이 대부분의 작업입니다. 각 Strapi 콘텐츠 유형은 Payload 수집이 됩니다. 필드는 거의 1:1로 매핑됩니다 -- 텍스트, 숫자, richtext, 관계, 미디어.
5. Strapi에서 데이터를 내보냅니다. PostgreSQL을 사용했다면 pg_dump를 사용하거나, Strapi REST API에 대한 스크립트를 작성하여 모든 콘텐츠를 가져옵니다.
6. Payload로 가져옵니다. 시드 스크립트에서 Payload의 Local API를 사용하여 대량 생성 콘텐츠.
7. 프론트엔드를 업데이트합니다. Strapi API 호출을 Payload Local API 호출(Server Components)이나 REST/GraphQL 호출(클라이언트 구성 요소)로 바꿉니다.
8. 배포합니다. Payload는 Next.js 내부에서 실행되므로 두 개 대신 하나의 애플리케이션을 배포합니다.

복잡한 마이그레이션의 경우, 우리의 headless CMS 개발 팀이 전환을 계획하는 데 도움을 줄 수 있습니다. 우리는 이것을 충분히 해봐서 지뢰가 어디인지 알고 있습니다.

성능 벤치마크 및 실제 숫자

중요한 숫자들입니다. 2025년 공개 벤치마크 및 우리 자신의 테스트로 수집됨:

메트릭	Strapi v5	Payload 3.x	Payload + Supabase
콜드 스타트 시간	500-2000ms	100-300ms	150-350ms
간단한 쿼리 (단일 항목)	45-80ms	8-15ms	10-20ms
복잡한 쿼리 (채워짐, 3 레벨)	200-500ms	30-80ms	40-100ms
관리 패널 로드	2-4s	1-2s	1-2s
빌드 시간 (500 페이지, ISR)	N/A (분리)	45-90s	50-100s
글로벌 지연 시간 (CDN 없음)	200-500ms	50-150ms	60-160ms

Supabase 연결 풀러는 직접 PostgreSQL 연결과 비교하여 작은 오버헤드를 추가하며, 일반적으로 5-15ms입니다. 실제로 무시할 수 있습니다.

한 가지 주의: Payload의 채워진 필드 쿼리 (깊은 관계 해결)는 원시 데이터베이스 쿼리보다 느린 것으로 표시되었습니다 -- GitHub 문제 #11325에 따르면 직접 Mongoose/Drizzle 호출보다 약 15배 느립니다. 읽기 집약적 페이지의 경우, 모든 요청에서 데이터베이스를 치는 것보다 Next.js ISR을 사용하거나 채워진 결과를 캐시하는 것을 권장합니다.

이 스택이 올바른 선택이 아닐 때

Payload + Supabase가 과도하거나 단순히 잘못된 시나리오를 언급하지 않으면 당신을 해칠 것입니다.

• 당신의 팀이 TypeScript를 쓰지 않습니다. Payload는 코드 우선입니다. 콘텐츠 팀이 모든 것을 관리하고 CMS를 유지하는 개발자가 없다면, Strapi의 GUI는 정말 더 낫습니다. 또는 Sanity나 Contentful을 보세요.
• 오늘 당신은 거대한 플러그인 생태계가 필요합니다. Payload의 생태계는 성장하고 있지만 Strapi의 100개 이상 확장보다 작습니다. Strapi 플러그인으로 존재하지만 Payload에서는 없는 특정 통합이 필요하면 빌드 시간을 고려하세요.
• 간단한 블로그나 마케팅 사이트를 구축하고 있습니다. Strapi는 이것을 위해 작동합니다. Astro와 headless CMS도 마찬가지입니다. 과도하게 엔지니어링하지 마세요.
• 엣지 우선 성능이 필요합니다. 글로벌 지연 시간이 50ms 미만이 하드 요구사항이면, Cloudflare Workers의 SonicJS를 보세요. Payload는 Node.js에서 실행됩니다 -- 빠르지만 엣지 기본이 아닙니다.

이 마이그레이션이 특정 프로젝트에 합리적인지 이야기하고 싶으십니까? 우리에게 연락하세요 -- 영업 홍보가 아닌 정직한 평가를 드리겠습니다.

FAQ

Payload CMS는 정말 무료입니까?

네. Payload는 MIT 라이선스이며 기능 제한 없이 자체 호스팅할 수 있습니다. 인프라를 관리하지 않으려는 팀을 위한 선택적 Payload Cloud 호스팅 서비스가 있지만 모든 CMS 기능 -- 라이브 미리보기, 액세스 제어, 로컬라이제이션, 버전 관리 -- 오픈 소스 버전에서 사용 가능합니다. 라이브 미리보기 및 콘텐츠 기록을 월 $45 Growth 플랜 뒤에 두는 Strapi와 비교해보세요.

Supabase를 자체만으로 CMS로 사용할 수 있습니까?

기술적으로 Supabase의 자동 생성 API 및 행 수준 보안을 사용하여 콘텐츠 관리 인터페이스를 구축할 수 있습니다. 하지만 Payload가 기본적으로 제공하는 것을 다시 만들고 있습니다: 관리 패널, 리치 텍스트 편집, 미디어 관리, 콘텐츠 버전 관리, 액세스 제어. Supabase는 백엔드 플랫폼이지, CMS가 아닙니다. 그것이 좋은 것에 사용하세요 -- 데이터베이스 호스팅, 인증, 저장소 -- 그리고 콘텐츠 레이어를 Payload에 맡기세요.

Strapi에서 Payload로 마이그레이션하는 데 얼마나 걸립니까?

10-20개의 콘텐츠 유형과 몇천 개의 항목이 있는 일반적인 프로젝트의 경우 개발자 시간으로 2-4주가 걸릴 것으로 예상합니다. 스키마 재생성이 가장 큰 부분입니다 -- Strapi 콘텐츠 유형을 Payload TypeScript 구성으로 변환. 데이터 마이그레이션은 일반적으로 좋은 스크립트로 1-2일입니다. 프론트엔드 업데이트는 코드가 Strapi의 API 응답 형식에 얼마나 밀접하게 결합되었는지에 따라 다릅니다. 데이터 액세스 레이어 또는 추상화를 사용한 팀이 더 쉬운 시간을 가질 것입니다.

Payload는 PostgreSQL 이외의 데이터베이스에서 작동합니까?

Payload는 공식 데이터베이스 어댑터를 통해 MongoDB와 PostgreSQL을 모두 지원합니다. 이 기사에 설명된 Supabase 스택의 경우 PostgreSQL 어댑터를 사용합니다. MongoDB 배경이 있다면 Payload의 MongoDB 어댑터는 실제로 MongoDB가 Payload의 원래 데이터베이스였기 때문에 더 성숙합니다. 둘 다 2025년에 프로덕션 준비가 되어 있습니다.

Strapi의 대안으로 Directus는 어떻습니까?

Directus는 견고한 옵션, 특히 CMS 인터페이스를 통해 노출하려는 기존 SQL 데이터베이스가 있다면. 데이터베이스 스키마에서 관리 패널 및 API를 자동 생성하며, 이는 영리합니다. Payload와 비교하면 주요 단점은 깊은 Next.js 통합이 부족합니다 -- Directus는 Strapi와 유사하게 별도의 서비스로 실행됩니다. Next.js/Vercel 스택이 없다면 Directus는 진지하게 고려할 가치가 있습니다.

Payload + Supabase를 Vercel에 배포할 수 있습니까?

절대로 -- 이것은 실제로 이상적인 배포 대상입니다. Payload는 Next.js 앱 내에서 실행되므로 Vercel에 배포하는 것은 Git 리포지토리로 푸시하는 것만큼 간단합니다. Supabase는 관리 서비스로 실행되므로 배포할 것이 없습니다. 전체 인프라는 다음이 됩니다: 계산 및 CDN을 위한 Vercel, 데이터베이스 및 인증을 위한 Supabase. 두 서비스, 하나의 배포 파이프라인. 우리는 Next.js 개발 실무를 통해 클라이언트를 위해 자주 이것을 설정합니다.

Payload 관리 패널은 사용자 정의할 수 있습니까?

매우. 관리자 UI는 React로 구축되었으며 사용자 정의 구성 요소, 사용자 정의 뷰, 사용자 정의 필드를 지원합니다. 대시보드 위젯을 추가하고, 사용자 정의 네비게이션 항목을 만들고, 기본 UI 요소를 재정의할 수 있습니다. Payload 3.x 이후로, 관리자 사용자 정의는 React Server Components를 사용하므로 사용자 정의 관리자 코드가 API 호출 없이 서버 측에서 데이터를 가져올 수 있습니다. 그것은 패칭 및 패칭이 필요한 Strapi의 관리자 확장 시스템과는 다른 세상입니다.

이 스택을 프로덕션에서 실행하는 데 드는 비용은 얼마입니까?

작은-중간 프로젝트의 경우: Vercel Pro는 월 $20 + Supabase Pro는 월 $25 = 총 월 $45. 이것은 서버리스 계산, 8GB 저장소가 있는 관리 PostgreSQL 데이터베이스, 250MB 파일 저장소, 50,000개의 월간 활성 인증 사용자, 자동 백업을 제공합니다. 필요에 따라 거기에서 확장하세요. 자체 호스팅 Strapi on a VPS (월 $20-50) + 자체 데이터베이스 관리 또는 Strapi Cloud의 Growth 플랜 월 $45 (제한된 좌석 포함)과 비교합니다. Payload + Supabase 조합은 비용 경쟁이며 운영하기 훨씬 더 쉽습니다. 자세한 프로젝트 예상은 우리의 가격 페이지를 확인하세요.