Giới thiệu

Trước bối cảnh chi phí bản quyền Oracle Database ngày càng tăng cao, làn sóng “thoát khỏi Oracle” đang tăng tốc mạnh mẽ trong các doanh nghiệp Nhật Bản.

Benesse Corporation đã chuyển từ môi trường Oracle on-premise lên cloud, cắt giảm chi phí phần cứng và bản quyền. Tanabe Mitsubishi Pharma đang dần chuyển đổi các hệ thống khả dụng sang PostgreSQL và SQL Server. Nhìn ra thế giới, Amazon — từng là một trong những người dùng Oracle lớn nhất — đã di chuyển hàng nghìn database và đạt được mức tiết kiệm hàng trăm triệu đô la, tạo ra tác động lớn đối với toàn ngành.

（出典：Làn sóng “thoát Oracle” tăng tốc tại Nhật Bản｜Business Journal）

ALLEXCEED VIETNAM cũng đã đồng hành cùng nhiều khách hàng trong việc thực hiện migration Oracle→PostgreSQL cho các hệ thống cốt lõi. Từ kinh nghiệm thực tiễn đó, chúng tôi nhận thấy rõ rằng: câu hỏi không còn là “có nên di chuyển hay không” mà là “khi nào và thực hiện thế nào”.

Tuy nhiên, việc di chuyển database hệ thống cốt lõi là dự án ảnh hưởng trực tiếp đến hoạt động kinh doanh. Bài viết này sẽ phân tích không chỉ những lợi ích mà còn cả rủi ro và tiêu chí ra quyết định, dựa trên kinh nghiệm thực tế của chúng tôi.

Tại sao làn sóng “thoát Oracle” đang tăng tốc?

Lý do 1: Vấn đề cơ cấu chi phí bản quyền

Oracle Database tuy hiệu năng cao nhưng cơ cấu bản quyền phức tạp. Chi phí tích lũy theo số lõi CPU và tính năng sử dụng, với phí bảo trì hàng năm tự động cộng thêm khoảng 20% giá bản quyền. Gần đây, Oracle liên tục thay đổi chính sách, ngừng cung cấp các sản phẩm entry-level và điều chỉnh giá.

Ngày càng nhiều khách hàng của chúng tôi tham khảo ý kiến về việc chuyển từ Oracle sang PostgreSQL. Khi xem xét migration nhân dịp xem lại chi phí bản quyền, cần một khoảng thời gian nhất định từ việc xác định phạm vi đến thực thi, vì vậy việc bắt đầu sớm là rất quan trọng.

Lý do 2: Sự cứng nhắc trong quản lý do vendor lock-in

Khi xây dựng hệ thống tối ưu hóa cho Oracle, doanh nghiệp rơi vào trạng thái “muốn chuyển sang DB khác cũng không được”. Phụ thuộc vào một vendor cụ thể hạn chế tự do lựa chọn cloud và về lâu dài có thể trở thành rủi ro quản lý.

Nhà báo công nghệ Takahiro Kodaira nhận xét: “Trong chiến lược IT thời đại cloud, cấu hình hệ thống linh hoạt rất quan trọng, nhưng cấu hình lấy Oracle DB làm trung tâm đôi khi khiến việc chuyển lên cloud hoặc chiến lược multi-cloud trở nên khó khăn hơn”.

Lý do 3: Sự trưởng thành về mặt kỹ thuật của PostgreSQL

PostgreSQL được lựa chọn không chỉ vì “miễn phí” mà còn vì năng lực kỹ thuật thực sự được đánh giá cao.

Trong bảng xếp hạng DB-Engines, PostgreSQL đứng thứ 4 thế giới (thực tế là số 1 trong OSS), được cung cấp dưới dạng managed service trên cả AWS, Azure và GCP. Với khả năng xử lý transaction, hỗ trợ JSON, tìm kiếm toàn văn bản, replication và nhiều tính năng khác, PostgreSQL ngày càng được áp dụng rộng rãi trong môi trường enterprise. （出典：DB-Engines Ranking｜DB-Engines）

Tất nhiên, Oracle có lợi thế về tính năng và sự ổn định được mài giũa qua nhiều năm. Nhưng trên thực tế, không có nhiều hệ thống đòi hỏi yêu cầu “chỉ Oracle mới đáp ứng được”, và PostgreSQL là lựa chọn kỹ thuật đủ mạnh cho phần lớn hệ thống nghiệp vụ. Điều quan trọng là đánh giá bình tĩnh sự cân bằng giữa chi phí và tính năng.

3 lợi ích khi chuyển sang PostgreSQL

Lợi ích 1: Cắt giảm đáng kể chi phí liên quan đến DB

PostgreSQL là open source, chi phí bản quyền phần mềm bằng 0. Ngay cả khi cần hỗ trợ thương mại, chi phí cũng chỉ bằng một phần nhỏ so với Oracle.

Hình ảnh so sánh chi phí 5 năm

※ Theo bảng giá chính thức của Oracle, Enterprise Edition được tính phí theo phương thức Named User Plus hoặc Processor. （出典：Oracle Technology Global Price List｜Oracle）

Ví dụ, nếu chi phí Oracle hàng năm là 5 triệu yên và dự án migration tốn 8 triệu yên, vốn đầu tư ban đầu sẽ được thu hồi trong khoảng 1,6 năm. Nếu tận dụng phát triển offshore để giảm chi phí dự án xuống 50～70%, thời gian thu hồi còn ngắn hơn nữa. Từ năm thứ 3 trở đi, hiệu quả tiết kiệm chi phí sẽ trực tiếp cải thiện lợi nhuận.

Hơn nữa, chi phí của chính dự án migration cũng có thể giảm khi tận dụng phát triển offshore. Đội ngũ Việt Nam có thể đảm nhận các công đoạn tốn nhiều nhân công như chuyển đổi SQL và kiểm thử với chi phí bằng 50～70% so với phát triển trong nước, từ đó nâng cao hơn nữa hiệu quả đầu tư tổng thể.

Lợi ích 2: Năng lực ứng phó với chiến lược multi-cloud

Vấn đề khi tiếp tục sử dụng Oracle trên cloud không chỉ là chi phí bản quyền. Khi đưa Oracle DB vào AWS hoặc Azure theo phương thức “BYOL (Bring Your Own License)”, các lõi CPU phía cloud trực tiếp là đối tượng tính phí Oracle, dẫn đến chi phí bản quyền ngang bằng hoặc cao hơn so với on-premise. Cũng có báo cáo về các trường hợp chi phí thực tế tăng gấp đôi khi chạy Oracle DB ngoài Oracle Cloud.

Trong khi đó, PostgreSQL được cung cấp dưới dạng managed service trên tất cả các cloud chính, chỉ cần trả phí sử dụng hạ tầng.

Điều quan trọng hơn là lấy lại tự do lựa chọn vendor. Khi chuyển sang PostgreSQL, doanh nghiệp có thể so sánh và lựa chọn cloud provider dựa trên chi phí, tính năng, region và mức độ phong phú của dịch vụ.

• Thiết kế tính khả dụng khi sự cố: Dễ dàng xây dựng cấu hình multi-AZ, multi-region phù hợp với yêu cầu RTO/RPO
• Kết hợp với dịch vụ cloud-native: Có thể kết hợp tự do các dịch vụ mới nhất như Bedrock (AI tạo sinh) của AWS hay Vertex AI của GCP mà không bị ràng buộc bởi phía DB
• Dư địa tối ưu hóa chi phí: Có thể tận dụng cạnh tranh giá giữa các cloud, tạo ra sức mạnh đàm phán để giảm chi phí vận hành dài hạn

Khi phụ thuộc vào một cloud vendor cụ thể, sức mạnh đàm phán giá sẽ bị mất đi mỗi lần gia hạn hợp đồng. Chuyển sang PostgreSQL là lựa chọn lấy lại chính tự do chiến lược cloud.

Lợi ích 3: Xây dựng nền tảng thúc đẩy DX

Báo cáo DX của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI) cảnh báo “vách đá 2025” — trạng thái “bận duy trì hệ thống legacy đến mức không thể dành người, tiền, thời gian cho việc thúc đẩy DX”. Nếu để nguyên, có nguy cơ thiệt hại kinh tế hơn 12 nghìn tỷ yên mỗi năm từ sau 2025. （出典：Báo cáo DX～Vượt qua “Vách đá 2025” của hệ thống IT～｜METI）

Tình trạng bị ràng buộc bởi chi phí bản quyền Oracle cao và cơ chế bảo trì phụ thuộc vào cá nhân chính là biểu tượng của “vách đá” này. Việc đổi mới DB sẽ cắt đứt chi phí hàng năm, khối lượng công việc và sự phụ thuộc đó, tạo ra nguồn lực để đầu tư vào DX.

PostgreSQL cũng có tính tương thích cao với nền tảng khai thác dữ liệu hiện đại.

• Kết nối native với công cụ BI: Các công cụ BI hàng đầu như Tableau, Looker, Redash đều hỗ trợ chuẩn PostgreSQL, cho phép trực quan hóa và phân tích dữ liệu mà không cần middleware bổ sung
• Kết nối với cấu trúc data lake: Dễ tích hợp với AWS Glue và Google BigQuery, dễ dàng xây dựng nền tảng khai thác dữ liệu toàn công ty
• Hỗ trợ AI và machine learning: Extension “pgvector” của PostgreSQL cho phép tìm kiếm vector, có thể sử dụng làm nền tảng triển khai các tính năng AI như RAG hay tìm kiếm kiến thức nội bộ
• Dễ tuyển dụng và đào tạo kỹ sư: Nguồn cung kỹ sư PostgreSQL vượt xa Oracle, giảm chi phí tuyển dụng và gánh nặng đào tạo nội bộ

Migration DB không phải là “thay thế hệ thống cũ” mà nên được coi là đầu tư xây dựng lại nền tảng để khai thác dữ liệu vào quản lý kinh doanh, từ đó trở thành điểm khởi đầu thúc đẩy DX.

3 rủi ro cần nắm bắt khi migration

Chỉ nhìn vào lợi ích để tiến hành migration là nguy hiểm. Migration DB hệ thống cốt lõi có những rủi ro đặc thù, và việc hiểu trước cùng với các biện pháp đối phó là chìa khóa thành công.

Rủi ro 1: “Bức tường chuyển đổi” do phương ngữ SQL và sự khác biệt tính năng

SQL của Oracle và PostgreSQL tương tự nhau nhưng không hoàn toàn tương thích. Cụ thể, sự khác biệt xảy ra trong các lĩnh vực sau:

• Viết lại hàm đặc thù Oracle (NVL→COALESCE, DECODE→CASE, v.v.)
• Tính năng package của PL/SQL (PostgreSQL không có khái niệm tương đương)
• Cách xử lý NULL và chuỗi rỗng (Oracle coi là như nhau, PostgreSQL phân biệt)
• Sự khác biệt cú pháp trigger và sequence

Khi chúng tôi thực hiện migration DB cho hệ thống cốt lõi của công ty điện lực, công đoạn tốn nhiều công nhất cũng là việc rà soát và kiểm tra chuyển đổi các điểm khác biệt này. Trong dự án đó, chúng tôi đã triển khai quy trình chuyển đổi tự động sử dụng AI để ngăn chặn lỗi chuyển đổi thủ công cho số lượng lớn DB object và SQL, nâng cao đáng kể hiệu quả công việc. Nếu làm cẩn thận ở đây, sự cố sau migration sẽ giảm đáng kể. （Trường hợp: Migration DB hệ thống quản lý nghiệp vụ doanh nghiệp điện lực）

（参考：Migration từ Oracle sang PostgreSQL, cần chú ý điều gì?｜SCSK）

Rủi ro 2: Sự khác biệt về đặc tính hiệu năng

Các query chạy nhanh trong môi trường Oracle đôi khi giảm hiệu năng trên PostgreSQL do hành vi xử lý nội bộ (optimizer) khác nhau.

Đặc biệt với các hệ thống phụ thuộc vào hint clause của Oracle hay sử dụng các tính năng đặc thù như bitmap index, việc kiểm thử hiệu năng sau migration là bắt buộc.

Từ kinh nghiệm hơn 800 dự án, chúng tôi khẳng định: giai đoạn kiểm thử chính là công đoạn quan trọng nhất quyết định thành bại của DB migration. Hãy nhất thiết đưa kiểm thử với lượng dữ liệu gần với thực tế vào kế hoạch migration.

Rủi ro 3: Phạm vi ảnh hưởng đến các hệ thống xung quanh

Dù chỉ thay thế DB, nếu các ứng dụng nghiệp vụ, xử lý batch, xuất báo cáo và kết nối bên ngoài được xây dựng với tiền đề là Oracle thì những thứ đó cũng cần phải sửa đổi.

Điều đặc biệt dễ bỏ sót là các phụ thuộc gián tiếp không kết nối trực tiếp với DB. Ví dụ, nếu ORM hay framework tạo ra SQL mà ứng dụng sử dụng, thì cũng cần kiểm tra tình trạng hỗ trợ PostgreSQL của thư viện đó. Việc rà soát rộng phạm vi ảnh hưởng từ giai đoạn đầu dự án là điểm quan trọng nhất để ngăn chặn làm lại ở các công đoạn sau.

4 tiêu chí để thực hiện migration thành công

Tiêu chí 1: Trực quan hóa độ khó migration bằng “kiểm kê” môi trường hiện tại

Trước khi quyết định migration, điểm khởi đầu là nắm bắt mức độ phụ thuộc của hệ thống hiện tại vào Oracle.

Cụ thể, kiểm tra các mục sau:

• Quy mô cấu trúc dữ liệu: Số bảng, lượng dữ liệu, xu hướng tăng trưởng
• Vị trí của logic: Bao nhiêu xử lý được viết trong stored procedure, trigger, view
• Số lượng hệ thống kết nối: Toàn cảnh xử lý phụ thuộc vào DB như ứng dụng nghiệp vụ, xử lý batch, kết nối bên ngoài
• Tình trạng sử dụng tính năng đặc thù Oracle: Sequence, partitioning, hàm đặc thù, v.v.

Kết quả kiểm kê này sẽ thay đổi lớn đến khối lượng công việc, thời gian và rủi ro của migration. Trước khi phán đoán “có thể migration hay không”, việc xác định “quy mô sẽ là bao nhiêu” là tiền đề cho quyết định đầu tư.

Công việc kiểm kê này có thể tự động hóa phần lớn bằng các công cụ hỗ trợ migration như ora2pg. Chạy tùy chọn --type SHOW_REPORT của ora2pg sẽ xuất ra danh sách object đặc thù Oracle, điểm tương thích SQL và ước tính khối lượng công việc. （参考：ora2pg Documentation｜ora2pg.darold.net）

Tiêu chí 2: So sánh chi phí bằng “TCO 5 năm”

Bản thân dự án migration cần đầu tư ban đầu. Nhưng điều cần phán đoán là không phải chi phí năm đơn lẻ mà là TCO (Tổng chi phí sở hữu) 5 năm.

Như Tanabe Mitsubishi Pharma đã thực hiện, phương pháp không migration tất cả cùng một lúc mà chuyển đổi từng bước từ các hệ thống có thể migration cũng rất hiệu quả. Bắt đầu nhỏ để chứng minh hiệu quả rồi triển khai từng bước giúp phân tán rủi ro và chi phí.

Ngoài ra, nếu tận dụng phát triển offshore, chi phí thực hiện dự án migration có thể giảm xuống 50～70% so với phát triển trong nước. Việc có đưa lựa chọn này vào tính toán TCO hay không đôi khi thay đổi kết luận của quyết định đầu tư.

Tiêu chí 3: Lựa chọn phương thức migration phù hợp với trạng thái hệ thống

Điều quan trọng là nắm bắt cân bằng chi phí và hiệu quả, rồi lựa chọn phương thức phù hợp với “trạng thái hệ thống hiện tại”.

Tiêu chí 4: Xây dựng thể chế kết hợp “kiến thức nghiệp vụ” và “kỹ thuật migration”

DB migration không thể thành công nếu không có cả người hiểu nghiệp vụ lẫn người có kỹ thuật migration.

• Thành viên nội bộ hiểu ý nghĩa dữ liệu và luồng nghiệp vụ
• Kỹ sư thành thạo chuyển đổi SQL, performance tuning và thiết kế kiểm thử

Khi nguồn lực kỹ sư nội bộ hạn chế, hợp tác với đối tác bên ngoài có kinh nghiệm migration là lựa chọn thực tế. Về các pattern thất bại dễ mắc phải khi lựa chọn đối tác offshore, hãy tham khảo thêm Học từ các trường hợp thất bại offshore — 5 pattern cần tránh và biện pháp đối phó.

Thể chế thực tế hoạt động tốt là phân công “thành viên nội bộ đảm nhận kiến thức nghiệp vụ và quyết định, đối tác bên ngoài đảm nhận thực thi kỹ thuật”. Phía nội bộ tập trung vào review thông số nghiệp vụ và UAT, còn chuyển đổi SQL, unit test, integration test giao cho bên ngoài.

Thực tế, trong dự án migration Oracle→PostgreSQL (quy mô 20 man-month) cho hệ thống cốt lõi của công ty điện lực, thể chế này đã duy trì độ ổn định cao như cơ sở hạ tầng xã hội trong khi đạt được mức giảm đáng kể chi phí bản quyền. （Xem trường hợp: Migration DB hệ thống quản lý nghiệp vụ doanh nghiệp điện lực）

Ngoài ra, trong ngành in ấn, khi migration Oracle→MariaDB, chúng tôi đã có kinh nghiệm phát triển công cụ migration chuyên dụng, giảm thiểu lỗi chuyển đổi thủ công và thực hiện dự án một cách hiệu quả. （Xem trường hợp: Phát triển công cụ migration dữ liệu từ Oracle sang MariaDB）

Tóm tắt: Di chuyển DB là “quyết định quản lý tấn công”

DB migration từ Oracle sang PostgreSQL không chỉ là biện pháp cắt giảm chi phí.

• Cắt giảm đáng kể chi phí cố định hàng năm, chuyển ngân sách dư sang đầu tư DX
• Thoát khỏi vendor lock-in, lấy lại tự do chiến lược cloud
• Xây dựng nền tảng thúc đẩy DX trong tương lai

Như các trường hợp của Benesse, Tanabe Mitsubishi Pharma và Amazon cho thấy, làn sóng này không phải xu hướng nhất thời mà là sự chuyển đổi cơ cấu mang tính doanh nghiệp lấy lại quyền chủ động với hạ tầng IT.

Chúng tôi đã liên tục đứng ở tiền tuyến phát triển offshore tại Việt Nam suốt gần 20 năm qua với hơn 800 dự án. Từ kinh nghiệm đó, một điều có thể khẳng định là: DB migration đã đến giai đoạn “thực hiện như thế nào” chứ không phải “có nên làm hay không”.

Để thành công, hãy nắm vững 4 điểm sau:

1. Kiểm kê môi trường hiện tại để nắm bắt định lượng độ khó migration
2. Phán đoán hiệu quả đầu tư bình tĩnh bằng TCO 5 năm (bao gồm cả lựa chọn offshore)
3. Lựa chọn phương thức migration phù hợp với trạng thái hệ thống
4. Xây dựng thể chế bao quát cả kiến thức nghiệp vụ lẫn kỹ thuật migration

Câu hỏi thường gặp

Q. Dự án migration từ Oracle sang PostgreSQL, thời gian dự kiến là bao lâu?
Khác nhau rất nhiều tùy theo quy mô, nhưng với hệ thống cốt lõi của công ty điện lực (quy mô 20 man-month), mục tiêu là khoảng 6～9 tháng để hoàn thành migration. Số bảng, lượng stored procedure và số lượng hệ thống kết nối trực tiếp ảnh hưởng đến tiến độ, nên việc kiểm kê để nắm bắt quy mô trước là quan trọng.

Q. Tại sao phí bảo trì hàng năm của Oracle lại cao như vậy?
Vì cơ cấu hợp đồng tự động cộng thêm ~22% giá bản quyền mỗi năm. Bản thân bản quyền đã đắt, lại không dễ hủy hay hạ cấp, nên chi phí càng tích lũy khi tiếp tục sử dụng.

Q. Chỉ dùng ora2pg có thể migration hoàn toàn tự động không?
ora2pg là công cụ xuất sắc có thể tự động xuất điểm tương thích SQL và ước tính khối lượng công việc của môi trường Oracle, nhưng không hỗ trợ migration hoàn toàn tự động. Luôn có các điểm đòi hỏi phán đoán và sửa đổi thủ công như chuyển đổi package PL/SQL hay sự khác biệt trong cách xử lý NULL/chuỗi rỗng. Kiểm thử hiệu năng với lượng dữ liệu gần với môi trường production cũng là công đoạn bắt buộc.

Q. Migration từng bước đối với hệ thống cốt lõi có thực tế không?
Hoàn toàn thực tế. Phương pháp “chuyển đổi từng bước từ các hệ thống có thể migration” như trường hợp Tanabe Mitsubishi Pharma có thể phân tán rủi ro và chi phí, hữu ích ngay cả trước khi áp dụng toàn diện cho hệ thống cốt lõi. Cách tiếp cận bắt đầu nhỏ để chứng minh hiệu quả rồi triển khai đã được định hình ở nhiều dự án thực tế.

Q. Chi phí khi phát đơn hàng DB migration cho offshore Việt Nam là bao nhiêu?
Tập trung vào các công đoạn tốn nhiều nhân công như chuyển đổi SQL, thiết kế kiểm thử, integration test, mức chi phí mục tiêu là khoảng 50～70% so với phát đơn trong nước. Kết hợp quy trình chuyển đổi tự động sử dụng AI còn có thể rút ngắn thêm chi phí và thời gian.

Q. Sau khi chuyển sang PostgreSQL, vận hành bảo trì có trở nên khó khăn hơn không?
Ngược lại, nhiều trường hợp sẽ dễ xây dựng thể chế hơn. Nguồn cung kỹ sư PostgreSQL vượt xa Oracle, giảm chi phí tuyển dụng và gánh nặng đào tạo nội bộ. Ngoài ra, nếu sử dụng managed service của AWS hay Azure, có thể giao phó việc quản lý vận hành DB cho phía cloud.

Q. So với các điểm đến migration khác (MySQL hay MariaDB) thì thế nào?
MySQL và MariaDB cũng là lựa chọn tiềm năng, nhưng PostgreSQL dẫn trước một bước trong môi trường enterprise. Hỗ trợ JSON, tìm kiếm toàn văn, window function, tìm kiếm vector qua pgvector… phạm vi khai thác dữ liệu rộng, tính tương thích với công cụ BI và AI cao. Thực tế, chúng tôi cũng có kinh nghiệm migration từ Oracle sang MariaDB, nhưng ngày càng nhiều khách hàng lựa chọn PostgreSQL như nền tảng thúc đẩy DX.

Q. Có thể chỉ đặt hàng phần “kiểm kê” trước không?
Có, hoàn toàn được. Có nhiều trường hợp chỉ đặt hàng khảo sát mức độ phụ thuộc của môi trường Oracle hiện tại và tính toán điểm độ khó trước khi phát đơn toàn bộ dự án migration. Đây là phương pháp phù hợp khi muốn chuẩn bị trước thông tin cần thiết cho quyết định quản lý “có nên migration hay không”. Xin hãy tham khảo ý kiến chúng tôi.

Chúng tôi sẽ đề xuất phương án phù hợp nhất cho dự án của bạn

Là công ty hàng đầu về giải pháp CNTT Nhật Bản với gần 20 năm kinh nghiệm phát triển offshore tại Việt Nam, chúng tôi cung cấp dịch vụ phát triển phần mềm và hệ thống.
Vui lòng liên hệ với chúng tôi khi bạn đang xem xét phát triển offshore.

Phát triển Offshore tại Việt Nam

Case Study | Tải tài liệu | Tư vấn miễn phí | Liên hệ qua LINE