PostgreSQL và SQLite trong n8n – Đâu là hệ quản trị cơ sở dữ liệu tốt nhất?

Giống như việc chọn nền móng cho một ngôi nhà, database không chỉ lưu trữ dữ liệu mà còn ảnh hưởng trực tiếp đến hiệu suất, khả năng mở rộng và sự ổn định của toàn bộ hệ thống. Với một công cụ mạnh mẽ như n8n, quyết định lựa chọn PostgreSQL hay SQLite không đơn thuần là vấn đề kỹ thuật, mà còn mang tính chiến lược. Vậy giữa PostgreSQL và SQLite trong n8n – Đâu là hệ quản trị cơ sở dữ liệu tốt nhất?

Tầm quan trọng của việc lựa chọn cơ sở dữ liệu cho n8n

n8n hoạt động với cơ sở dữ liệu như thế nào?

n8n sử dụng cơ sở dữ liệu để lưu trữ các thành phần cốt lõi sau:

• Workflows: Định nghĩa của các luồng công việc, bao gồm các node, kết nối và cấu hình.
• Credentials: Thông tin xác thực cho các dịch vụ bên ngoài (API keys, OAuth tokens, …).
• Executions: Lịch sử thực thi của các workflow, bao gồm trạng thái, đầu vào, đầu ra và lỗi (nếu có).
• Settings: Các cài đặt chung của n8n.

Khi n8n khởi động, nó sẽ kết nối với cơ sở dữ liệu đã cấu hình để tải các workflow và credentials. Trong quá trình hoạt động, nó sẽ ghi lại lịch sử thực thi và cập nhật trạng thái của các workflow vào cơ sở dữ liệu. Do đó, hiệu suất và độ tin cậy của cơ sở dữ liệu ảnh hưởng trực tiếp đến trải nghiệm sử dụng và khả năng hoạt động của n8n.

Vì sao cơ sở dữ liệu quan trọng với n8n?

Trong n8n, cơ sở dữ liệu không chỉ là nơi lưu trữ workflow, credentials hay lịch sử thực thi, mà còn là nền tảng bảo đảm tính ổn định và hiệu suất của toàn bộ hệ thống. Một lựa chọn database phù hợp sẽ giúp:

• Đảm bảo hiệu năng xử lý workflow: Khi số lượng workflow tăng, n8n phải xử lý song song nhiều tiến trình. Cơ sở dữ liệu mạnh mẽ sẽ tối ưu việc đọc/ghi dữ liệu, giảm độ trễ và ngăn nghẽn cổ chai.
• Tăng khả năng mở rộng: Doanh nghiệp khi triển khai n8n ở quy mô lớn thường cần hỗ trợ clustering, queue mode hoặc tích hợp với message broker. Điều này đòi hỏi một hệ quản trị cơ sở dữ liệu có khả năng mở rộng tốt.
• Đảm bảo tính toàn vẹn và bảo mật dữ liệu: Workflow trong n8n thường liên quan đến dữ liệu nhạy cảm (email khách hàng, API keys, dữ liệu CRM). Cơ sở dữ liệu đóng vai trò quan trọng trong việc bảo vệ, mã hóa và quản lý quyền truy cập.
• Hỗ trợ khôi phục và duy trì hệ thống: Một cơ sở dữ liệu đáng tin cậy giúp dễ dàng backup, restore và hạn chế rủi ro mất dữ liệu khi hệ thống gặp sự cố.
• Tối ưu chi phí vận hành: Lựa chọn database phù hợp với quy mô sẽ tránh lãng phí tài nguyên. Ví dụ: SQLite đủ cho cá nhân hoặc dự án nhỏ, trong khi PostgreSQL là lựa chọn tối ưu cho hệ thống production.

👉 Nói cách khác, database là trái tim của n8n. Một quyết định đúng ngay từ đầu sẽ giúp bạn tiết kiệm thời gian, chi phí và tránh rủi ro khi mở rộng hệ thống trong tương lai.

Tổng quan về SQLite

SQLite là gì?

SQLite là một hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) nhưng lại vô cùng đặc biệt. Không giống như các “đàn anh” như PostgreSQL hay MySQL yêu cầu một tiến trình máy chủ (server process) chạy riêng biệt, SQLite là “serverless” (không máy chủ), “self-contained” (khép kín) và “zero-configuration” (không cần cấu hình).

Nói một cách đơn giản, toàn bộ cơ sở dữ liệu của bạn được chứa gọn trong một file duy nhất ngay trên máy chủ của bạn (thường là file database.sqlite trong thư mục .n8n). n8n tương tác trực tiếp với file này thông qua một thư viện mà không cần cài đặt thêm bất kỳ phần mềm database nào. Đây cũng chính là lý do tại sao n8n có thể bắt đầu hoạt động gần như ngay lập tức sau khi cài đặt.

Ưu điểm của SQLite: Đơn giản, gọn nhẹ và không cần cài đặt

• Cài đặt tức thì: Vì SQLite được tích hợp sẵn, bạn không cần phải trải qua các bước cài đặt, cấu hình user, mật khẩu hay phân quyền phức tạp. Chỉ cần khởi chạy n8n, database đã sẵn sàng.
• Tính di động cao: Toàn bộ trạng thái của n8n (workflows, credentials, execution logs) nằm gọn trong một file. Bạn có thể dễ dàng sao lưu, di chuyển hoặc sao chép instance n8n của mình chỉ bằng cách copy file database.sqlite và thư mục .n8n.
• Không tốn tài nguyên: SQLite không chạy một tiến trình nền nào, do đó nó tiêu thụ rất ít RAM và CPU. Điều này làm cho nó trở nên hoàn hảo cho việc chạy trên các thiết bị cấu hình thấp như Raspberry Pi, máy tính cá nhân hoặc các gói VPS giá rẻ.
• Bảo trì đơn giản: Bạn không cần phải lo lắng về việc quản trị một hệ thống database phức tạp. Việc bảo trì gần như bằng không.

Nhược điểm của SQLite: Hạn chế về truy cập đồng thời và khả năng mở rộng

Sự đơn giản của SQLite cũng chính là nguồn gốc của những hạn chế lớn nhất, đặc biệt trong môi trường sản xuất (production):

• Vấn đề khóa cơ sở dữ liệu (Database Locking): SQLite chỉ cho phép một tiến trình ghi vào cơ sở dữ liệu tại một thời điểm. Khi n8n thực thi nhiều workflow cùng lúc, tất cả chúng đều cố gắng ghi lại log. Tiến trình đầu tiên sẽ khóa file database, các tiến trình còn lại phải xếp hàng chờ. Nếu thời gian chờ quá lâu, chúng sẽ báo lỗi “database is locked”, dẫn đến việc workflow bị thất bại.
• Không có khả năng mở rộng: SQLite bị giới hạn bởi tài nguyên của một máy chủ duy nhất. Bạn không thể tách database ra một máy chủ riêng để nâng cao hiệu suất. Khi file database ngày càng lớn do ghi nhiều log, hiệu năng truy vấn sẽ giảm sút đáng kể.
• Thiếu các tính năng nâng cao: So với PostgreSQL, SQLite thiếu nhiều tính năng quản trị chuyên nghiệp như phân quyền người dùng chi tiết, replication (nhân bản), hay các cơ chế sao lưu/phục hồi tại một thời điểm (point-in-time recovery) phức tạp.

Tổng quan về PostgreSQL

PostgreSQL là gì?

PostgreSQL, thường được gọi là “Postgres”, là một hệ quản trị cơ sở dữ liệu đối tượng-quan hệ (ORDBMS) mã nguồn mở mạnh mẽ và tiên tiến. Nếu SQLite là một tệp tin đơn giản, thì PostgreSQL là một hệ thống máy chủ-máy khách (client-server) hoàn chỉnh.

Điều đó có nghĩa là PostgreSQL chạy như một dịch vụ riêng biệt, lắng nghe các kết nối từ những ứng dụng khác (như n8n). Dịch vụ này được thiết kế ngay từ đầu để xử lý khối lượng công việc lớn, nhiều người dùng đồng thời và các bộ dữ liệu phức tạp.

Với hơn 30 năm phát triển, PostgreSQL nổi tiếng toàn cầu về sự ổn định, tính toàn vẹn dữ liệu và khả năng mở rộng, khiến nó trở thành lựa chọn hàng đầu cho các ứng dụng quan trọng trong môi trường sản xuất (production).

Ưu điểm của PostgreSQL: Mạnh mẽ, ổn định và giàu tính năng

Khi sử dụng PostgreSQL cho n8n, bạn sẽ mở khóa được toàn bộ tiềm năng của nền tảng tự động hóa này:

• Xử lý đồng thời vượt trội: PostgreSQL sử dụng kiến trúc kiểm soát đồng thời đa phiên bản (MVCC – Multiversion Concurrency Control). Hiểu đơn giản, nó cho phép nhiều workflow đọc và ghi vào cơ sở dữ liệu cùng một lúc mà không khóa lẫn nhau. Điều này loại bỏ hoàn toàn lỗi “database is locked” của SQLite và đảm bảo hệ thống chạy mượt mà dù có hàng trăm workflow thực thi song song.
• Độ tin cậy và toàn vẹn dữ liệu tuyệt đối: Postgres tuân thủ nghiêm ngặt các tiêu chuẩn ACID, đảm bảo mọi giao dịch đều được xử lý một cách trọn vẹn. Các tính năng như sao lưu tại một thời điểm (Point-in-Time Recovery), ghi nhật ký ghi trước (Write-Ahead Logging) và nhân bản (replication) giúp bảo vệ dữ liệu của bạn khỏi các sự cố phần cứng hoặc lỗi hệ thống.
• Hiệu năng cao cho khối lượng lớn: Được tối ưu hóa để xử lý hàng triệu bản ghi, PostgreSQL có thể quản lý lịch sử thực thi (execution logs) khổng lồ của n8n mà không làm giảm hiệu suất. Cơ chế lập chỉ mục (indexing) thông minh và trình tối ưu hóa truy vấn (query optimizer) tinh vi giúp truy xuất dữ liệu cực kỳ nhanh chóng.
• Khả năng mở rộng linh hoạt: Bạn có thể chạy PostgreSQL trên một máy chủ chuyên dụng, mạnh mẽ hơn nhiều so với máy chủ chạy n8n. Khi cần, bạn có thể dễ dàng “scale up” (nâng cấp phần cứng máy chủ) hoặc “scale out” (sử dụng các cụm database) để đáp ứng nhu cầu ngày càng tăng.

Nhược điểm của PostgerSQL: Phức tạp hơn trong cài đặt và quản lý

Sức mạnh của PostgreSQL đi kèm với một vài đánh đổi:

• Cài đặt và cấu hình phức tạp: Không giống như SQLite “chạy ngay lập tức”, việc thiết lập PostgreSQL đòi hỏi nhiều bước hơn: cài đặt phần mềm máy chủ, tạo cơ sở dữ liệu, tạo người dùng (user), phân quyền và cấu hình kết nối mạng.
• Yêu cầu tài nguyên hệ thống cao hơn: Vì là một tiến trình máy chủ chạy liên tục, PostgreSQL tiêu thụ nhiều RAM và CPU hơn đáng kể so với SQLite, ngay cả khi ở trạng thái nghỉ.
• Cần kiến thức quản trị: Để vận hành trơn tru, bạn cần có kiến thức cơ bản về quản trị cơ sở dữ liệu, chẳng hạn như cách sao lưu, phục hồi, theo dõi hiệu năng và cập nhật phiên bản. Tuy nhiên, các dịch vụ database được quản lý (Managed Database) trên cloud như Amazon RDS, Google Cloud SQL có thể đơn giản hóa công việc này.

So sánh chi tiết PostgreSQL và SQLite trong n8n

1. Hiệu năng và khả năng xử lý đồng thời

Đây là khác biệt lớn nhất và quan trọng nhất giữa hai hệ quản trị cơ sở dữ liệu này.

• SQLite: Hoạt động dựa trên cơ chế khóa toàn bộ file (database-level locking) khi thực hiện thao tác ghi. Điều này có nghĩa là tại một thời điểm, chỉ có một workflow có thể ghi lại log thực thi. Nếu có 10 workflows cùng kết thúc, 9 cái còn lại sẽ phải “xếp hàng” chờ đợi. Nếu hàng đợi quá đông hoặc một tác vụ ghi quá lâu, n8n sẽ báo lỗi database is locked. Đây là “gót chân Achilles” khiến SQLite không phù hợp cho các hệ thống có nhiều tác vụ chạy song song.
• PostgreSQL: Sử dụng kiến trúc máy chủ-máy khách và cơ chế kiểm soát đồng thời đa phiên bản (MVCC). Nó cho phép hàng trăm, hàng ngàn kết nối đọc và ghi diễn ra cùng lúc mà không xung đột lẫn nhau. Mỗi workflow có thể ghi log vào database một cách độc lập, đảm bảo thông lượng cao và hệ thống luôn phản hồi nhanh chóng, ngay cả dưới tải nặng.

Kết luận: PostgreSQL chiến thắng tuyệt đối về hiệu năng xử lý đồng thời, yếu tố sống còn cho một hệ thống tự động hóa hiệu quả.

2. Khả năng mở rộng (Scalability)

Khi hệ thống tự động hóa của bạn phát triển, cơ sở dữ liệu phải có khả năng đáp ứng theo.

• SQLite: Khả năng mở rộng gần như bằng không. Nó bị giới hạn hoàn toàn trong tài nguyên của một máy chủ duy nhất (chỉ có thể scale up bằng cách nâng cấp CPU/RAM/đĩa của máy chủ đó). Khi file database lớn dần, hiệu suất sẽ suy giảm tuyến tính. Bạn không thể tách database ra một máy chủ chuyên dụng.
• PostgreSQL: Được thiết kế để mở rộng. Bạn có thể:
  • Scale Up: Chuyển database sang một máy chủ riêng biệt với cấu hình cực mạnh.
  • Scale Out: Sử dụng các kỹ thuật nâng cao như nhân bản (replication) để tạo các bản sao chỉ đọc (read replicas), giúp giảm tải cho database chính, hoặc phân mảnh (sharding) để chia nhỏ dữ liệu ra nhiều máy chủ.

Kết luận: PostgreSQL cung cấp một lộ trình mở rộng rõ ràng và mạnh mẽ, trong khi SQLite bị bó hẹp trong giới hạn của một máy chủ đơn.

3. Cài đặt và bảo trì

• SQLite: Vô địch về sự đơn giản. Nó không cần cài đặt, không cần cấu hình, không cần quản trị. Mọi thứ đã được tích hợp sẵn trong n8n. Việc sao lưu chỉ đơn giản là copy một file database.sqlite. Đây là lý do nó là lựa chọn mặc định hoàn hảo để bắt đầu.
• PostgreSQL: Đòi hỏi nhiều công sức hơn đáng kể. Bạn phải cài đặt PostgreSQL server, tạo database, tạo người dùng, phân quyền, và cấu hình chuỗi kết nối trong n8n. Việc bảo trì (sao lưu, cập nhật, theo dõi hiệu năng) cũng cần kiến thức kỹ thuật nhất định. Tuy nhiên, các dịch vụ cloud (Managed Databases) đã giúp đơn giản hóa quá trình này rất nhiều.

Kết luận: SQLite dễ sử dụng hơn cho người mới bắt đầu, nhưng sự phức tạp của PostgreSQL được đền đáp bằng sức mạnh và sự ổn định.

4. An toàn và toàn vẹn dữ liệu

• SQLite: Tuân thủ các nguyên tắc ACID, đảm bảo tính toàn vẹn cho các giao dịch. Tuy nhiên, vì là một file đơn lẻ, nó dễ bị lỗi hoặc hỏng hóc hơn nếu máy chủ bị tắt đột ngột hoặc gặp sự cố về đĩa cứng. Các công cụ phục hồi cũng hạn chế hơn.
• PostgreSQL: Nổi tiếng là một trong những cơ sở dữ liệu đáng tin cậy nhất. Nó tuân thủ ACID một cách nghiêm ngặt và cung cấp hàng loạt cơ chế bảo vệ dữ liệu ở cấp độ doanh nghiệp:
  • Write-Ahead Logging (WAL): Đảm bảo không mất dữ liệu ngay cả khi hệ thống gặp sự cố.
  • Point-in-Time Recovery (PITR): Cho phép khôi phục database về chính xác một thời điểm bất kỳ trong quá khứ.
  • Replication: Tạo các bản sao dữ liệu theo thời gian thực để dự phòng.

Kết luận: Đối với dữ liệu kinh doanh quan trọng, PostgreSQL cung cấp một cấp độ an toàn và khả năng phục hồi vượt trội hoàn toàn so với SQLite.

5. Hệ sinh thái và cộng đồng hỗ trợ

Cả hai đều là dự án mã nguồn mở với cộng đồng lớn mạnh.

• SQLite: Được sử dụng trong hàng tỷ thiết bị và ứng dụng trên toàn thế giới, có tài liệu hướng dẫn rất tốt cho các trường hợp sử dụng cơ bản.
• PostgreSQL: Có một cộng đồng phát triển cực kỳ năng động và một hệ sinh thái công cụ khổng lồ xung quanh nó. Từ các công cụ quản trị giao diện (pgAdmin, DBeaver) đến các tiện ích mở rộng mạnh mẽ (PostGIS cho dữ liệu địa lý, TimescaleDB cho dữ liệu chuỗi thời gian), bạn có thể tìm thấy giải pháp cho gần như mọi vấn đề. Khi gặp sự cố, việc tìm kiếm sự trợ giúp cho PostgreSQL thường dễ dàng hơn cho các vấn đề phức tạp.

Kết luận: Cả hai đều có cộng đồng tốt, nhưng hệ sinh thái công cụ và hỗ trợ cho các vấn đề ở quy mô lớn của PostgreSQL đa dạng và mạnh mẽ hơn.

Dưới đây là bảng tổng kết so sánh nhanh PostgreSQL và SQLite:

Khi nào chọn SQLite? Khi nào chọn PostgreSQL?

Chọn SQLite khi:

• Môi trường phát triển và thử nghiệm: Khi bạn đang xây dựng và gỡ lỗi các workflow trên máy tính cá nhân của mình, sự tiện lợi và nhanh chóng của SQLite là hoàn hảo nhất.
• Sử dụng cá nhân: Nếu bạn chỉ dùng n8n cho các dự án tự động hóa cá nhân với số lượng workflow không nhiều và tần suất chạy thấp (vài lần một giờ).
• Hệ thống có quy mô rất nhỏ: Dành cho các đội nhóm siêu nhỏ hoặc doanh nghiệp mới bắt đầu, nơi chỉ có 1-2 người dùng và dưới 100 workflow thực thi mỗi ngày.
• Các ứng dụng nhúng hoặc Demo: Khi bạn cần nhúng n8n vào một giải pháp lớn hơn hoặc tạo một bản demo nhanh cho khách hàng mà không muốn phụ thuộc vào một hệ thống database bên ngoài.

Chọn PostgreSQL khi:

• Môi trường Production: Bất kỳ instance n8n nào phục vụ cho mục đích kinh doanh, chạy các quy trình tự động hóa quan trọng, đều phải sử dụng PostgreSQL để đảm bảo sự ổn định và an toàn dữ liệu.
• Lỗi “Database is Locked” xuất hiện thường xuyên: Đây là dấu hiệu rõ ràng nhất cho thấy SQLite không còn khả năng xử lý khối lượng công việc đồng thời của bạn.
• Có nhiều người dùng hoặc nhiều workflow chạy song song: Nếu team của bạn có nhiều người cùng xây dựng và chạy workflow, hoặc hệ thống của bạn xử lý nhiều webhook, tác vụ theo lịch trình cùng lúc.
• Khi hiệu suất bắt đầu suy giảm: Giao diện người dùng n8n trở nên chậm chạp, việc tải lịch sử thực thi mất nhiều thời gian. Điều này thường xảy ra khi tệp SQLite phình to (vượt quá 1-2 GB).
• Khi bạn cần khả năng phục hồi sau thảm họa (Disaster Recovery): Nếu việc mất dữ liệu workflow hoặc lịch sử thực thi là không thể chấp nhận được, bạn cần các tính năng sao lưu và nhân bản mạnh mẽ của PostgreSQL.

Một số yếu tố cần cân nhắc khi lựa chọn

Khi đưa ra quyết định, hãy xem xét các yếu tố sau:

• Quy mô và tốc độ tăng trưởng dự kiến: Dự án của bạn sẽ phát triển đến mức nào? Số lượng workflow và lượt thực thi có tăng nhanh không? Nếu có, hãy nghĩ đến PostgreSQL ngay từ đầu.
• Tài nguyên hệ thống: Bạn có đủ tài nguyên (CPU, RAM, dung lượng đĩa) để chạy một máy chủ PostgreSQL riêng biệt không?
• Kinh nghiệm của đội ngũ: Đội ngũ của bạn có kinh nghiệm với việc quản lý cơ sở dữ liệu không? Hay bạn muốn một giải pháp đơn giản, ít cần bảo trì?
• Yêu cầu về tính sẵn sàng và bảo mật: Mức độ quan trọng của dữ liệu và quy trình tự động hóa của bạn là gì? Bạn có cần các tính năng bảo mật và sẵn sàng cao cấp không?
• Chi phí: Mặc dù cả hai đều miễn phí cấp phép, nhưng chi phí vận hành và quản lý có thể khác nhau đáng kể.

Hướng dẫn cách chuyển đổi từ SQLite sang PostgreSQL cho n8n

Bước 1: Chuẩn bị môi trường PostgreSQL

Trước tiên, bạn cần một cơ sở dữ liệu PostgreSQL đang hoạt động. Bạn có thể sử dụng một dịch vụ managed database (như Amazon RDS, Google Cloud SQL) hoặc tự host bằng Docker.

Nếu bạn tự host, đây là cách đơn giản để khởi tạo PostgreSQL bằng Docker:

docker run --name n8n-postgres -p 5432:5432 -e POSTGRES_USER=n8n -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_DB=n8n -d postgres 

Lệnh này sẽ:

• Tạo một container tên là n8n-postgres.
• Tạo một người dùng (POSTGRES_USER) tên là n8n.
• Đặt mật khẩu (POSTGRES_PASSWORD) là mysecretpassword (bạn nên đổi mật khẩu này thành một mật khẩu mạnh hơn).
• Tạo một database (POSTGRES_DB) tên là n8n.

Dù bạn dùng cách nào, hãy ghi lại các thông tin sau để sử dụng ở các bước tiếp theo:

• Host: Địa chỉ IP hoặc hostname của server PostgreSQL (ví dụ: localhost hoặc 192.168.1.10).
• Port: Cổng kết nối (mặc định là 5432).
• User: n8n.
• Password: Mật khẩu bạn đã đặt.
• Database Name: n8n.

Bước 2: Dừng n8n và Sao lưu (Quan trọng!)

Dừng container n8n đang chạy:

docker stop your-n8n-container-name

Sao lưu toàn bộ thư mục cấu hình: Thư mục này thường nằm ở ~/.n8n.

# Tạo một file backup dạng nén

zip -r n8n-backup-before-postgres.zip ~/.n8n

# Hoặc đơn giản là copy thư mục

cp -r ~/.n8n ~/.n8n-backup

Bước 3: Chạy lệnh di chuyển dữ liệu

n8n cung cấp một lệnh CLI đặc biệt để xuất dữ liệu từ database cũ và nhập vào database mới. Chúng ta sẽ chạy lệnh này bằng một container Docker tạm thời.

Hãy đảm bảo bạn đang ở trong thư mục chứa thư mục .n8n của bạn (ví dụ: thư mục home ~).

Mở terminal và chạy lệnh sau. Hãy thay thế các giá trị trong ngoặc < > bằng thông tin PostgreSQL của bạn.

docker run --rm -it \

-v ~/.n8n:/home/node/.n8n \

-e DB_TYPE=postgresdb \

-e DB_POSTGRESDB_HOST=<YOUR_POSTGRES_HOST> \

-e DB_POSTGRESDB_PORT=<YOUR_POSTGRES_PORT> \

-e DB_POSTGRESDB_DATABASE=<YOUR_POSTGRES_DATABASE> \

-e DB_POSTGRESDB_USER=<YOUR_POSTGRES_USER> \

-e DB_POSTGRESDB_PASSWORD=<YOUR_POSTGRES_PASSWORD> \

-e DB_POSTGRESDB_SCHEMA=public \

n8nio/n8n:latest \

n8n export:database

Giải thích lệnh:

• docker run –rm -it: Chạy một container tạm thời và tự xóa sau khi hoàn thành.
• -v ~/.n8n:/home/node/.n8n: Mount thư mục cấu hình cục bộ của bạn vào trong container. Đây là cách n8n đọc được file database.sqlite.
• -e …: Các biến môi trường để n8n biết cách kết nối đến PostgreSQL.
• n8nio/n8n:latest: Sử dụng phiên bản n8n mới nhất.
• n8n export:database: Lệnh thực thi việc di chuyển.

Bạn sẽ thấy các log hiện ra trên màn hình. Nếu mọi thứ thành công, nó sẽ báo Migration finished successfully! Quá trình này có thể mất vài phút nếu bạn có nhiều dữ liệu lịch sử thực thi.

Bước 4: Cấu hình n8n để sử dụng PostgreSQL

Bây giờ dữ liệu đã ở trong PostgreSQL, chúng ta cần cấu hình n8n để nó luôn sử dụng database mới này. Bạn cần thêm các biến môi trường ở Bước 3 vào lệnh docker run hoặc file docker-compose.yml của mình.

Cách 1: Sử dụng docker run

Thêm các biến -e vào lệnh khởi động n8n của bạn:

docker run -d --name n8n \

-p 5678:5678 \

-v ~/.n8n:/home/node/.n8n \

-e DB_TYPE=postgresdb \

-e DB_POSTGRESDB_HOST=<YOUR_POSTGRES_HOST> \

-e DB_POSTGRESDB_PORT=<YOUR_POSTGRES_PORT> \

-e DB_POSTGRESDB_DATABASE=<YOUR_POSTGRES_DATABASE> \

-e DB_POSTGRESDB_USER=<YOUR_POSTGRES_USER> \

-e DB_POSTGRESDB_PASSWORD=<YOUR_POSTGRES_PASSWORD> \

-e DB_POSTGRESDB_SCHEMA=public \

n8nio/n8n:latest

Cách 2: Sử dụng docker-compose.yml (Khuyến nghị)

Đây là cách quản lý tốt hơn. Cập nhật file docker-compose.yml của bạn:

version: '3.7'

services:

n8n:

image: n8nio/n8n:latest

restart: always

ports:

- "127.0.0.1:5678:5678"

environment:

- DB_TYPE=postgresdb

- DB_POSTGRESDB_HOST=<YOUR_POSTGRES_HOST>

- DB_POSTGRESDB_PORT=<YOUR_POSTGRES_PORT>

- DB_POSTGRESDB_DATABASE=<YOUR_POSTGRES_DATABASE>

- DB_POSTGRESDB_USER=<YOUR_POSTGRES_USER>

- DB_POSTGRESDB_PASSWORD=<YOUR_POSTGRES_PASSWORD>

- DB_POSTGRESDB_SCHEMA=public

# Thêm các biến môi trường khác của bạn ở đây

- N8N_HOST=your.domain.com

- N8N_PROTOCOL=https

volumes:

- ~/.n8n:/home/node/.n8n

Bước 5: Khởi động lại n8n và kiểm tra

Bây giờ hãy khởi động n8n với cấu hình mới:

# Nếu dùng docker-compose

docker-compose up -d

# Nếu dùng docker run (hãy xóa container cũ trước)

docker rm n8n

# Chạy lại lệnh docker run ở Bước 4

Sau khi n8n khởi động, hãy truy cập vào giao diện web. Kiểm tra kỹ:

• Tất cả các workflows của bạn có còn không?
• Tất cả các credentials có còn không?
• Lịch sử Executions có hiển thị đầy đủ không?

Nếu mọi thứ đều ở đó, xin chúc mừng! Bạn đã di chuyển thành công n8n sang PostgreSQL. Bạn có thể xóa file database.sqlite trong thư mục .n8n để tiết kiệm dung lượng, nhưng hãy giữ lại bản backup bạn đã tạo ở Bước 2 trong vài ngày để đề phòng.

Kết luận

Cả PostgreSQL và SQLite đều có chỗ đứng riêng khi triển khai với n8n. Nếu bạn chỉ cần một giải pháp nhẹ, nhanh chóng cho cá nhân hoặc dự án nhỏ, SQLite hoàn toàn đáp ứng tốt. Ngược lại, khi hướng đến hệ thống lớn, nhiều luồng xử lý, đòi hỏi tính bảo mật và khả năng mở rộng, PostgreSQL gần như là lựa chọn mặc định. Điều quan trọng là hiểu rõ nhu cầu và quy mô của workflow trong n8n để chọn công cụ phù hợp, thay vì chạy theo xu hướng.

Những câu hỏi thường gặp