ที่เก็บข้อมูล MinIO ไม่ได้รับการดูแลรักษาอีกต่อไป
(github.com/minio)- มีการแก้ไขไฟล์ README.md เพื่อระบุอย่างชัดเจนว่าโปรเจกต์นี้ ไม่ได้รับการดูแลรักษาอีกต่อไป
- ข้อความเดิม “maintenance mode” ถูกลบออก และแทนที่ด้วยคำเตือน “THIS REPOSITORY IS NO LONGER MAINTAINED”
- ด้านบนของ README มีการเสนอทางเลือกทดแทน 2 แบบ คือ AIStor Free และ AIStor Enterprise
- มีการแก้ไขข้อผิดพลาดของลิงก์ในเอกสาร และแก้ URL ของช่อง Slack ให้ถูกต้อง
- การเปลี่ยนแปลงนี้ยืนยันว่าที่เก็บโอเพนซอร์สของ MinIO ถูกเปลี่ยนเป็นสถานะ อ่านอย่างเดียว (archive) แล้ว
การเปลี่ยนแปลงสำคัญใน README.md
-
ส่วน “Maintenance Mode” เดิมถูกลบออกทั้งหมด และแทนที่ด้วย บล็อกหมายเหตุใหม่
- บล็อกใหม่นี้มีข้อความ “THIS REPOSITORY IS NO LONGER MAINTAINED” รวมอยู่ด้วย
- ใต้หัวข้อ “Alternatives” มีการระบุผลิตภัณฑ์ทางเลือก 2 รายการ
- AIStor Free: เวอร์ชันสแตนด์อโลนฟรีสำหรับชุมชน
- AIStor Enterprise: เวอร์ชันสำหรับใช้งานแบบดีพลอยที่มีการสนับสนุนเชิงพาณิชย์รวมอยู่ด้วย
-
ลิงก์คำแนะนำการสมัครใช้งานที่เกี่ยวข้องกับ AIStor ในเอกสารเดิมถูกลบออก และสรุปใหม่เป็นคำอธิบายทางเลือกที่กระชับกว่าเดิม
การแก้ไขและจัดระเบียบอื่น ๆ
- ลิงก์ Slack ถูกแก้จาก
https//slack.min.ioที่ไม่ถูกต้อง เป็นhttps://slack.min.io - ใน ตัวอย่างตัวแปรสภาพแวดล้อม มีการแก้คำพิมพ์ผิดจาก
GOARChเป็นGOARCH - คำสะกดผิดใน ข้อความไลเซนส์ AGPLv3 จาก
liabilitesถูกแก้เป็นliabilities - ในส่วน “Legacy Binary Releases” มีการเพิ่มบรรทัดว่าง 1 บรรทัดเพื่อให้อ่านง่ายขึ้น
สถานะของที่เก็บข้อมูล
- ที่ด้านบนของหน้า GitHub แสดงข้อความว่า “This repository was archived by the owner on Feb 13, 2026. It is now read-only.”
- ซึ่งหมายความว่าที่เก็บนี้ถูก เก็บถาวร (archive) และไม่สามารถแก้ไขหรือมีส่วนร่วมเพิ่มเติมได้อีกต่อไป
ความหมาย
- พร้อมกับการแก้ไข README ที่เก็บนี้ได้เข้าสู่สถานะ ยุติการบำรุงรักษาและถูกเก็บถาวร อย่างเป็นทางการ
- มีการแนะนำให้เปลี่ยนจาก MinIO เวอร์ชันโอเพนซอร์สไปใช้ผลิตภัณฑ์ตระกูล AIStor Free/Enterprise แทน
- การสนับสนุนจากชุมชนยังคงมีผ่าน GitHub และ Slack ในรูปแบบ best-effort
1 ความคิดเห็น
ความเห็นจาก Hacker News
ผมคิดว่าไม่มีปัญหาอะไรที่ MinIO จะปิดโอเพนซอร์ส
มีคนจำนวนมากทั่วโลกที่ ใช้งานฟรีอย่างเดียว
ผมทดสอบทางเลือกอื่นมาตั้งแต่หลายเดือนก่อน และมองว่าหลัง MinIO แล้ว RustFS จะเป็นผู้ชนะ
ผมเปรียบเทียบ Garage, SeaweedFS, Ceph และ RustFS แล้วพบว่า RustFS กับ SeaweedFS เร็วที่สุด และการติดตั้งกับคอนโซลของ RustFS ก็สะดวกที่สุด
Ceph ซับซ้อนเกินไปจนยากจะดีพลอยได้ถ้าไม่เข้าใจซอร์สโค้ดอย่างลึกซึ้ง
มีเสียงวิจารณ์ว่า CLA ของ RustFS เป็น “เหยื่อล่อ” แต่ผมคิดว่ามันไม่เกินเลยในฐานะกลไกเพื่อลดความเสี่ยงทางกฎหมาย
ที่ Milvus เองก็ประเมิน RustFS ในแง่ดี และเมื่อดูจากตัวชี้วัดทางเทคนิคแล้วผมเชื่อว่า RustFS จะชนะในท้ายที่สุด
บทความประเมิน RustFS ของ Milvus
ปัญหาผู้ใช้ฟรีมีอยู่จริง และใน ยุค AI มันยิ่งรุนแรงขึ้น
มีผู้ใช้จำนวนมากใช้โปรเจ็กต์ฟรี แต่สัดส่วนที่เปลี่ยนมาเป็นลูกค้าแบบชำระเงินนั้นต่ำมาก
Milvus ต้องการอ็อบเจ็กต์สตอเรจที่ดีกว่าเพื่อความเสถียรและประสิทธิภาพ และ RustFS ก็เป็นตัวเลือกที่มีแนวโน้มมาก
แต่ในระยะยาว ถ้าอีโคซิสเต็มยังตอบโจทย์ไม่ได้ ก็อาจต้องพิจารณาสร้างเอง
จำเป็นต้องมี การถกเถียงเรื่องความยั่งยืน ของโมเดลไลเซนส์โอเพนซอร์ส
โมเดลแบบยุค Apache 2.0 เริ่มเห็นข้อจำกัดแล้ว และแนวทางที่แค่ “หวังว่าบริษัทต่าง ๆ จะช่วยสนับสนุน” ก็ใช้ไม่ได้อีกต่อไป
การตัดสินใจของ MinIO จึงน่าจับตาในฐานะสัญญาณของความเปลี่ยนแปลงนี้
ตอนตั้งค่ามันซับซ้อน แต่ตอนนี้เสถียรมาก
Claude Code ยอดเยี่ยมมากสำหรับการดูแล Ceph และจัดการทั้งการกู้คืนหรือแก้ไข CRUSH map ได้ง่าย
คำพูดที่ว่า “ถ้าไม่เข้าใจซอร์สโค้ดอย่างลึกซึ้งก็ deploy ไม่ได้” ผมว่าพูดเกินจริง
ถ้า Ceph เหมาะกับงานของคุณ ผมแนะนำให้ลองจริงจัง
แค่ติดตั้งไบนารีตัวเดียวแล้วเขียนไฟล์คอนฟิก
/etc/garage.tomlก็พอจะรันด้วย
garage serverหรือให้ AI ช่วยเขียน init script ให้ก็ได้AIStore ของ NVIDIA ก็เป็นระบบที่รองรับ S3 ได้ยอดเยี่ยม ดูได้ที่ เว็บไซต์ทางการของ AIStore
มันเร็วกว่า MinIO แต่ประสิทธิภาพการใช้พื้นที่จะด้อยกว่านิดหน่อย
SeaweedFS ให้ความรู้สึกเหมือนโปรเจ็กต์ส่วนตัวค่อนข้างมาก และถ้าไม่แบ็กอัปบ่อย ๆ ก็เสี่ยง
ผมอยากหลีกเลี่ยง RustFS เพราะปัญหาเรื่อง CLA ทำให้ดูเหมือนจะเป็น การซ้ำรอยกรณี MinIO
มันทำงานเป็นหน่วย volume และอัปเดตก็ทำในระดับ volume
แต่อ็อบเจ็กต์สตอเรจทั่วไปมักถูกใช้เป็นแบ็กเอนด์สำหรับงานวิเคราะห์ด้วย จึงต้องการการสแกนความเร็วสูง
เพราะฉะนั้น SeaweedFS จึงมี trade-off ที่ต่างจากอ็อบเจ็กต์สตอเรจแบบใช้งานทั่วไป
หลังจากเลิกทำบริการโอเพนซอร์สแล้ว ความเหนื่อยล้าเรื้อรัง ก็หายไป
การทำงานฟรีมันไม่สนุก และการดูแลทั้งเวอร์ชันเสียเงินกับเวอร์ชันคอมมูนิตีพร้อมกันก็เหนื่อยมาก
ความสัมพันธ์กับผู้ใช้ที่ไม่จ่ายเงินสุดท้ายก็กลายเป็นความเครียด
ดูเหมือนว่าทีม MinIO ก็ได้บทเรียนแบบเดียวกัน
พวกเขาใช้โมเดล COSS (Commercial Open Source Software) คือให้เวอร์ชันพื้นฐานฟรี แล้วขายฟีเจอร์แบบเสียเงินให้ลูกค้าองค์กร
การเปลี่ยนไปใช้ซอร์สปิดก็เป็นแค่การตัดสินใจทางธุรกิจ
ผมใช้ SeaweedFS ในโปรดักชันมานาน และตอนนี้ก็ใช้งานร่วมกับ Wasabi อยู่
SeaweedFS ยังยอดเยี่ยมมากสำหรับงานสตอเรจโลคัลที่ต้องการความเร็ว
ควรบอกแผนให้ชัดตั้งแต่ต้น
ถ้าไม่ได้ทำแบบนั้น ก็ควรรักษาคำมั่นเดิมไว้
ตอนนี้ผมดูแล storage engine ที่ชื่อ TidesDB ต่อให้ปวดหลังก็ยังทำต่อ เพราะชอบมันจริง ๆ
ประสบการณ์แบบนี้เป็นเรื่องส่วนบุคคล แต่แน่นอนว่ามันสนุกได้จริง
ผมย้ายจาก MinIO ไป Ceph สำเร็จแล้ว
ผมก็ทดสอบ SeaweedFS ด้วย แต่พอวิเคราะห์บั๊กด้วยความช่วยเหลือของ Claude ก็พบว่าโครงสร้างโค้ดเละมาก
ไม่ควรใช้ SeaweedFS กับอะไรนอกจากการทดสอบเด็ดขาด เพราะมีความเสี่ยงข้อมูลสูญหายสูง
มีความพยายามทำตัวเลือกอื่นมากมาย แต่สุดท้าย Ceph ก็ยังเป็นตัวที่จัดการความซับซ้อนของปัญหานี้ได้ดีที่สุด
ช่วงนี้ผมกำลังย้าย MinIO ไป Ceph
ผมสร้างคลัสเตอร์ Ceph แบบ 3 เซิร์ฟเวอร์ด้วย cephadm และกำลังทำ replication ข้อมูล 120TB ที่ความเร็ว 420MB/s
Ceph ซับซ้อนกว่า MinIO แต่ ขยายระบบได้ดี และเสถียร
น่าเสียดายที่คอนโซลของ MinIO หายไป
ผมเลือก Ceph เพราะ Elasticsearch ไม่ชอบ S3 snapshot ของ Garage
เพียงแต่ต้องระวังไม่ให้ดิสก์ของโหนดเต็ม
น่าสนใจที่หลายคนยังรีบทดสอบ ทางเลือกที่ยังไม่ผ่านการพิสูจน์ในโปรดักชัน
ความเสี่ยงที่แท้จริงของการพึ่งพาอินฟราคือไม่ใช่เรื่องซอร์สปิด แต่คือ ต้นทุนในการย้ายออก
ถึงจะบอกว่ารองรับ S3 เหมือนกัน แต่การย้ายจริงมักกินเวลาหลายสัปดาห์ถึงหลายเดือนเพราะความต่างเล็ก ๆ น้อย ๆ
ผมสงสัยว่าผู้ใช้ MinIO จะมีสักกี่รายที่เอกสารแผนการย้ายระบบไว้อย่างเป็นเรื่องเป็นราว
มีการพูดถึง AIStore ว่าเป็นทางเลือกของ MinIO
นอกจากนี้ยังมีตัวเลือกโอเพนซอร์สอีกหลายตัว:
Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph
มันมี S3 gateway และทำ proxy การเรียก S3 ไปยัง SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive ฯลฯ
เป็นระบบแบบ stateless อย่างสมบูรณ์ และเชื่อมต่อกับแบ็กเอนด์ได้หลากหลาย
ในโค้ดก็มีการเตรียมความพร้อมสำหรับการเปลี่ยนไลเซนส์ไว้แล้ว
Ceph เป็นตัวที่ฟีเจอร์ S3 ใกล้เคียงที่สุด แต่คอนฟิกซับซ้อนและอ่อนไหวต่อ latency
Garage เหมาะกับการเก็บข้อมูลแบบง่าย ๆ แต่ยังขาดฟีเจอร์อย่าง ACL ขั้นสูงของ S3 หรือข้อจำกัดด้าน path
ระบบคลัสเตอร์ของมันเป็นมิตรกับ WAN แต่ไม่จำเป็นต้องจัดวางเป็นระดับ rack แบบ Ceph
ดูเหมือนตอนนี้ยังไม่มีทางเลือกที่ง่ายแบบนั้น
แม้ฟีเจอร์ด้านการจัดการจะยังขาด แต่ในแง่ความถูกต้องสมบูรณ์ของข้อมูล ผมยังเชื่อใจ Ceph มากกว่า
Ceph ให้ความรู้สึกว่าเป็นผลงานของคนที่เข้าใจระบบกระจายอย่างลึกซึ้งจริง ๆ
ลิงก์ PR
ถ้าดู เธรด HN ก่อนหน้า จะเห็นได้ว่า MinIO เข้าสู่โหมด maintenance ไปแล้วก่อนหน้านี้
ตั้งแต่ตอนนั้นก็นับว่าเป็นการส่งสัญญาณล่วงหน้าถึงการเปลี่ยนไปเป็นซอร์สปิด
MinIO ขาดความโปร่งใสมาตั้งแต่ก่อนแล้ว และห่างไกลจากจิตวิญญาณโอเพนซอร์ส ทั้งการ ลบ issue ที่วิจารณ์ หรือการล็อกคอมเมนต์
เพราะแบบนั้นทันทีที่มันเข้าสู่โหมด maintenance ผมก็ย้ายไป Garage
ผมกำลังเตรียม PR อยู่ แต่ยังไม่ได้ส่ง
โอเพนซอร์สจริงจังส่วนใหญ่ได้รับการสนับสนุนจากภาคอุตสาหกรรม และยากที่นักพัฒนาเว็บทั่วไปจะมีส่วนร่วมได้
ผมแนะนำให้ ฟอร์กเก็บไว้ในเครื่อง เผื่อกรณีที่รีโพ MinIO ถูกลบ
รีโพสาธารณะบน GitHub ถ้าถูกลบ ฟอร์กยังคงอยู่ แต่ถ้าเปลี่ยนเป็น private ฟอร์กจะหายไปด้วย
เคยมีเหตุการณ์คล้ายกันกับ Gem ชื่อ prawn_plus ในอีโคซิสเต็ม Ruby
ดู เอกสารนโยบายฟอร์กของ GitHub
สำหรับคนที่ใช้ MinIO แค่เพื่อทดสอบในเครื่อง มันอาจกลายเป็น กับดักที่ค่อย ๆ ปิดลง
หากคุณกำลังใช้งานโซลูชันด้าน Observability ที่ต้องพึ่งอ็อบเจ็กต์สตอเรจ เช่น Thanos, Loki, Mimir, Tempo
ลองพิจารณา VictoriaMetrics, VictoriaLogs, VictoriaTraces แทนได้
พวกมันใช้บล็อกสตอเรจเป็นฐาน ขยายได้ถึงระดับเพตะไบต์ และให้ทั้งประสิทธิภาพกับความพร้อมใช้งานสูงโดยไม่ต้องดูแลจัดการด้วยตนเองมากนัก