먼저 결정하기: 환경 변수만 바꾸지 않습니다
적합: 기존 n8n의 업무 데이터가 필요하고, 이전 범위와 원본 백업을 정한 뒤 공식 경로로 검증할 수 있는 경우입니다.
부적합: 데이터 복사 없이 설정만 바꿔 이전을 끝내려는 경우입니다. SQLite의 기존 데이터는 새 PostgreSQL 데이터베이스에 자동으로 옮겨지지 않습니다.
개인 개발자는 과거 실행 기록이 실제로 필요한지부터 판단합니다. 필요하지 않다면 새 데이터베이스에 필요한 업무 데이터만 옮기는 방법을 검토할 수 있습니다. 기록을 보존해야 하는 팀은 적용 가능한 이전 방법을 먼저 시험해야 합니다. 커뮤니티에서 공유된 스크립트가 모든 버전과 데이터에 맞는다고 보아서는 안 됩니다.
이 글은 SQLite를 장기간 운영 중인 독립 개발자, 팀의 워크플로와 사용자 관계를 유지해야 하는 담당자, 그리고 n8n 2.x 업그레이드와 데이터베이스 이전을 분리해 계획하는 책임자를 위한 안내입니다.
마지막 업데이트: 2026년 10월 31일. 데이터베이스 설정, 명령줄 도구와 버전 변경 사항은 n8n 공식 데이터베이스 안내, 명령줄 안내 및 2.0 이전 보고서를 기준으로 확인해야 합니다. 실제 작업 전에는 사용 중인 버전의 문서와 복제 인스턴스를 다시 점검합니다.
유지 관리 유형에 따라 이전 범위 나누기
모든 운영자가 같은 데이터를 옮겨야 하는 것은 아닙니다. 개인 시험 환경은 필요한 워크플로와 자격 증명만으로 충분할 수 있지만, 팀 운영 환경은 사용자와 프로젝트, 공유 관계까지 확인해야 할 수 있습니다.
| 운영자 유형 | 우선 확인할 사항 | 판단 기준 |
|---|---|---|
| 개인 시험 사용자 | 기존 데이터가 실제로 필요한지, 백업을 복원할 수 있는지 | 업무 데이터가 필요 없으면 새 환경을 구성하고 필요한 항목만 이전합니다. |
| 개인 운영 담당자 | 워크플로, 자격 증명, 사용자 설정과 실행 기록 | 꼭 필요한 항목과 현재 버전에서 옮길 수 있는 항목을 구분합니다. |
| 소규모 팀 유지 관리자 | 사용자, 프로젝트, 공유와 워크플로 소유 관계 | 가져온 뒤 팀 구성원별 접근 범위를 복제 환경에서 확인합니다. |
| 실행 기록 보존 담당자 | 기록 보존 정책, 이전 방법, 저장 공간과 복구 결과 | 공식 지원 여부를 확인하고, 검증되지 않은 방법은 운영에 적용하지 않습니다. |
n8n은 SQLite를 기본 데이터베이스로 사용할 수 있고 PostgreSQL 설정도 제공합니다. 하지만 데이터베이스 연결 설정은 데이터를 복사하는 절차와 다릅니다. 공식 데이터베이스 설정 안내에서 대상 버전에 맞는 설정 항목을 확인하고, 데이터 이전 자체는 별도 작업으로 계획합니다.
두 번째 단계: 가져올 데이터를 항목별로 확정하기
| 데이터 범주 | 이전 전 확인 | 놓치기 쉬운 위험 |
|---|---|---|
| 워크플로 | 내보낼 대상과 가져올 대상, 기존 항목과 식별자 중복 여부 | 가져오기 옵션에 따라 기존 항목이 덮어써질 수 있습니다. |
| 자격 증명 | 원본 암호화 키의 보관 및 대상 환경의 키 설정 | 키가 맞지 않으면 가져온 자격 증명을 사용할 수 없을 수 있습니다. |
| 사용자와 프로젝트 | 사용자 목록, 프로젝트 연결, 공유 관계 | 워크플로와 자격 증명만으로 팀의 권한 구성이 복원된다고 단정할 수 없습니다. |
| 실행 기록 | 보존 필요성, 적용 가능한 이전 방법, 복구 가능성 | 일반적인 항목 내보내기와 같은 방식으로 옮겨진다고 가정하지 않습니다. |
| 이진 데이터 | 사용 중인 저장 방식과 파일 위치 | 데이터베이스 외부에 저장된 파일은 별도로 확인해야 할 수 있습니다. |
n8n 공식 명령줄 문서는 워크플로와 자격 증명의 가져오기 및 내보내기를 설명하며, 가져오기 때 식별자 처리에 유의하도록 안내합니다. 명령줄 도구 문서에서 실제 버전의 명령과 옵션을 확인하고, 기존 데이터가 있는 대상에 곧바로 가져오지 않습니다.
자격 증명은 암호화 키까지 함께 검토해야 합니다. 키의 존재만 확인하는 데 그치지 말고, 복제 환경에서 자격 증명을 이용하는 워크플로가 실제 연결에 성공하는지 확인합니다. 키를 잃어버렸거나 값이 일치하는지 확신할 수 없다면, 원본을 보존한 채 복구 가능성을 먼저 시험합니다.
팀 구성원이 함께 사용하는 워크플로라면 공유 관계도 점검 대상입니다. 공식 워크플로 공유 안내를 참고하되, 문서에 나온 공유 기능이 특정 이전 경로에서 자동 복원된다는 뜻으로 해석하지 않습니다. 사용자별로 보이는 워크플로와 프로젝트를 대조해야 합니다.
세 번째 단계: 데이터베이스 이전과 버전 변경 분리하기
| 선택지 | 적용하기 좋은 상황 | 먼저 확인할 점 |
|---|---|---|
| PostgreSQL만 먼저 적용 | 데이터베이스 변경 영향을 분리해 살펴보려는 경우 | 현재 n8n 버전의 PostgreSQL 설정과 이전 절차를 확인합니다. |
| 데이터베이스 이전 후 버전 업그레이드 | 운영 변경을 단계별로 검증할 수 있는 경우 | 각 단계의 완료 조건과 되돌리기 지점을 따로 정합니다. |
| 이전과 업그레이드를 함께 진행 | 변경을 분리하기 어려운 제약이 있는 경우 | 원인 추적이 어려워질 수 있으므로 복제 환경의 검증을 강화합니다. |
업그레이드 책임자는 먼저 현재 버전과 목표 버전을 기록하고, 공식 변경 안내와 이전 보고서에서 적용 가능한 항목을 확인합니다. n8n 2.0 변경 안내와 이전 보고서는 버전 관련 점검의 출발점입니다. 커뮤니티 사례 하나만으로 다른 버전에서도 같은 절차가 지원된다고 결론 내리지 않습니다.
조건에 따라 경로 선택하기
- 백업에서 원본을 복원할 수 있고, 필요한 데이터 범위가 정해져 있다면 복제 환경에서 공식 경로를 검증한 뒤 이전합니다.
- 과거 실행 기록이 필요하지 않고 이전 가능성이 확인된 업무 데이터만 필요하다면 새 PostgreSQL 환경에 필요한 항목만 옮기는 선택지를 검토합니다.
- 실행 기록이나 팀 권한 관계를 반드시 보존해야 하지만 적용 가능한 공식 절차를 확인하지 못했다면, 운영 전환을 보류하고 복제본에서 이전 결과와 복구 가능성을 확인합니다.
- n8n 2.x 업그레이드가 함께 예정되어 있다면 데이터베이스 이전을 먼저 검증하고, 버전 업그레이드는 별도 변경으로 계획합니다.
- 백업 복원 시험에 실패하거나 원본 암호화 키를 확보하지 못했다면 전환하지 않습니다. 백업과 키를 확보한 뒤 다시 판단합니다.
네 번째 단계: 되돌릴 수 있는 절차로 실행하기
다음 순서로 작업하면 설정 변경과 데이터 이전을 혼동할 가능성을 줄일 수 있습니다.
- 현재 상태를 기록합니다. n8n 버전, 데이터베이스 종류와 설정, 이진 데이터 저장 방식, 사용자와 프로젝트 구성을 확인합니다. 민감한 값은 문서나 작업 기록에 평문으로 남기지 않습니다.
- 원본 백업을 만들고 복원을 시험합니다. 백업 파일이 있다는 사실만으로 복구가 보장되지는 않습니다. 별도 복제 환경에서 복원할 수 있는지 확인하고, 전환 전까지 원본을 보존합니다.
- 이전 범위를 정합니다. 워크플로와 자격 증명 외에 사용자 설정, 공유 관계, 실행 기록, 이진 데이터가 필요한지 항목별로 결정합니다. 확인되지 않은 항목은 자동 이전된다고 가정하지 않습니다.
- 복제 환경에서 공식 절차를 시험합니다. 현재 버전 문서에 있는 설정과 명령을 기준으로 작업합니다. 가져오기 전 대상 데이터와 식별자 충돌 여부를 확인합니다.
- 사용자 역할별로 검증합니다. 운영자와 일반 구성원이 로그인하고, 필요한 워크플로를 확인하며, 자격 증명을 사용하는 작업을 시험합니다.
- 실행 경로와 기록을 확인합니다. 수동 실행뿐 아니라 정해진 시간에 실행되는 작업과 웹훅 호출을 확인합니다. 기록 보존이 요구된다면 이전 전후의 범위와 복구 결과를 따로 비교합니다.
- 전환과 중단 조건을 결정합니다. 필수 검증이 모두 통과한 경우에만 실제 전환을 진행합니다. 권한, 자격 증명, 실행 결과에 차이가 있으면 새 환경을 계속 사용하지 말고 사전에 정한 복귀 절차를 따릅니다.
실행 기록의 보존과 정리는 데이터베이스 이전과 별도로 살펴야 합니다. 공식 실행 데이터 안내에서 현재 버전에 해당하는 보존 설정을 확인합니다. 실행 기록이 늘어날 때 필요한 저장 공간은 실제 사용량과 보존 정책을 바탕으로 산정해야 하며, PostgreSQL로 바꾼 것만으로 백업이나 고가용성이 마련되는 것은 아닙니다.
이진 데이터도 데이터베이스 안에만 있다고 단정하지 않습니다. 저장 방식에 따라 별도 파일 경로가 관련될 수 있으므로 공식 이진 데이터 안내를 확인하고, 데이터베이스 백업과 파일 백업이 모두 복원 가능한지 시험합니다.
다섯 번째 단계: 역할별로 완료 여부 확인하기
| 확인 역할 | 실제로 확인할 항목 | 완료 판단 |
|---|---|---|
| 유지 관리자 | 로그인, 설정 접근, 사용자와 프로젝트 구성 | 필요한 관리 기능과 구성이 원본과 맞습니다. |
| 워크플로 담당자 | 워크플로 목록, 소유 관계, 공유 범위와 활성 상태 | 업무에 필요한 흐름이 보이고 의도한 구성원에게만 접근이 허용됩니다. |
| 자격 증명 담당자 | 자격 증명을 사용하는 실제 연결과 작업 | 연결 오류 없이 필요한 작업을 실행할 수 있습니다. |
| 운영 담당자 | 예약 실행, 웹훅, 실행 기록과 파일 복원 | 업무 트리거가 작동하고 필요한 데이터 복구가 확인됩니다. |
확인 결과는 단순히 “페이지가 열린다”로 끝내지 않습니다. 이전 전후에 사용자별로 보이는 워크플로가 달라졌는지, 기존 자격 증명을 쓰는 자동화가 성공하는지, 실행 기록이 필요한 범위만큼 남아 있는지 기록합니다. 나중에 원인을 추적할 수 있도록 변경 단계와 검증 결과도 보관합니다.
서버를 고를 때는 실제 데이터베이스 증가량, 이진 데이터 크기, 실행 기록 보존 정책과 백업 사본을 합쳐 저장 공간을 계산합니다. PostgreSQL을 n8n과 같은 서버에 둘지 분리할지도 함께 검토하되, 같은 서버에 배치한다고 백업이나 장애 대비가 자동으로 제공되지는 않습니다. 운영 데이터의 취급과 보관 조건을 검토할 때는 데이터 처리 안내를 참고하고, 대여 주기와 청구 조건은 대여 요금 안내에서 확인합니다.
자주 확인하는 이전 질문
SQLite에서 PostgreSQL로 옮길 때는 어떤 순서가 적절한가요?
데이터베이스 설정을 바꾸기 전에 원본 백업과 복원 가능성을 확인합니다. 그다음 보존할 데이터 범위를 정하고, 사용 중인 n8n 버전의 공식 절차를 복제 환경에서 시험합니다. 이전이 끝나면 로그인, 워크플로 실행, 자격 증명 호출과 사용자별 접근 범위를 확인합니다. 설정만 바꾸는 것은 데이터 이전이 아닙니다.
데이터베이스를 바꾸면 워크플로와 자격 증명은 그대로 남나요?
기존 데이터가 새 PostgreSQL 데이터베이스에 자동 복사되지는 않습니다. 공식 명령줄 도구가 지원하는 워크플로와 자격 증명 내보내기 및 가져오기를 확인하고, 식별자 덮어쓰기 가능성과 암호화 키를 함께 점검합니다. 팀 환경에서는 사용자, 프로젝트, 공유 관계도 별도 확인이 필요합니다. 복제 환경에서 실제 자격 증명 호출까지 시험한 뒤 운영에 적용합니다.
과거 실행 기록도 반드시 이전해야 하나요?
보존 의무나 장애 조사에 필요한지 먼저 판단합니다. 실행 기록은 워크플로와 자격 증명과 같은 방식으로 다룰 수 있다고 단정해서는 안 됩니다. 유지해야 한다면 현재 버전에서 적용 가능한 절차와 기록 완전성, 복구 가능성을 시험합니다. 지원 여부가 확인되지 않은 커뮤니티 스크립트를 운영 데이터에 바로 적용하지 않습니다.
n8n 2.x 업그레이드와 데이터베이스 이전은 함께 해도 되나요?
가능하다고 미리 단정하기보다 변경을 분리할 수 있는지 먼저 검토합니다. 공식 변경 안내와 이전 보고서에서 현재 버전과 목표 버전에 해당하는 내용을 확인하고, 복제 환경에서 데이터베이스 변경과 버전 업그레이드를 각각 시험합니다. 단계별로 로그인, 공유 관계, 자격 증명과 실행 결과를 대조하고, 문제가 생겼을 때 원본으로 돌아갈 조건을 정합니다.
전환 전에 서버 선택도 별도로 판단합니다
기존 공유형 서버는 다른 작업과 자원을 함께 쓸 수 있고, 실제 CPU 자원 배분이나 저장 방식의 선택 폭이 운영 환경에 따라 제한될 수 있습니다. 장기 실행 중인 n8n과 PostgreSQL을 계속 함께 운영하면서 자원 사용과 데이터 위치를 직접 관리해야 한다면, 이런 조건은 이전 이후의 안정성과 운영 계획에도 영향을 줍니다. 반대로 시험용이거나 실행이 드물고 부하가 가벼운 환경이라면 공유형 서비스가 더 간단할 수 있습니다.
독립 AMD 물리 서버를 선택해도 이전 데이터가 자동으로 복사되거나 백업, 고가용성이 제공되는 것은 아닙니다. 다만 한 대의 서버를 독점해 운영하는 방식을 검토하면 공유 환경의 자원 경합을 피하고, n8n과 PostgreSQL의 배치와 저장 공간을 자체 계획에 맞춰 관리할 수 있습니다. 데이터베이스 증가량과 백업 방식을 먼저 정한 뒤, XFP Cloud의 서버 제품 정보에서 실제 제공되는 저장 공간, 운영 체제와 대여 조건을 확인하고 배치를 결정합니다.
자주 묻는 질문
n8n에서 SQLite를 PostgreSQL로 바꿀 때 어떤 순서로 진행해야 하나요?
환경 변수만 바꾸면 기존 SQLite 데이터가 새 PostgreSQL 데이터베이스로 복사되는 것은 아닙니다. 먼저 원본을 백업하고 필요한 데이터 범위를 정한 뒤, 현재 n8n 버전의 공식 문서에서 지원하는 이전 방법을 확인합니다. 작업은 복제 환경에서 검증하고, 실제 전환 뒤에는 로그인과 워크플로 실행까지 확인한 다음 원본을 보존합니다.
데이터베이스를 옮겨도 워크플로와 자격 증명을 계속 사용할 수 있나요?
워크플로와 자격 증명은 공식 명령줄 도구의 내보내기와 가져오기 지원 범위를 확인해 옮길 수 있습니다. 다만 가져오기 옵션에 따라 기존 항목을 덮어쓸 수 있고, 자격 증명 복호화에는 원래 인스턴스의 암호화 키가 필요할 수 있습니다. 이전 전에 키 보관 위치와 가져오기 대상 식별자를 확인하고, 복제 환경에서 실제 호출까지 시험해야 합니다.
n8n 데이터베이스 이전 때 과거 실행 기록도 반드시 가져와야 하나요?
과거 실행 기록이 업무 감사나 장애 추적에 필요하지 않다면, 이를 유지해야 하는지부터 보존 정책과 함께 판단합니다. 실행 기록은 워크플로와 자격 증명과 다른 데이터 범주이며, 일반적인 내보내기와 가져오기만으로 전체 기록이 이전된다고 가정하면 안 됩니다. 기록을 보존해야 한다면 현재 버전에서 가능한 방법과 복구 결과를 별도로 시험하고, 검증되지 않은 커뮤니티 스크립트는 운영 데이터에 바로 적용하지 않습니다.
n8n 2.x로 올리기 전에 데이터베이스 이전 위험을 어떻게 확인하나요?
데이터베이스 이전과 n8n 버전 업그레이드를 한 작업으로 묶지 말고 각각 별도 검증 대상으로 둡니다. 현재 버전과 목표 버전의 공식 변경 안내 및 이전 보고서를 읽고, 복제본에서 데이터 이전만 먼저 시험합니다. 이후 버전 업그레이드를 따로 적용해 로그인, 공유 관계, 자격 증명 호출과 실행 결과를 비교합니다. 문제가 생기면 되돌릴 원본과 중단 조건도 사전에 정합니다.