DoltLite ขึ้น Beta — SQLite ที่ branch/merge/diff ได้ เขียนด้วย PR ราว 2,000 ใบจากทีมเอเจนต์ ผ่านเทสต์ TCL ของ SQLite 99.46% จาก 892,277 ข้อ

31 สิงหาคม 2026 Tim Sehn ซีอีโอ DoltHub ประกาศว่า DoltLite เวอร์ชัน 0.50.0 เข้าสถานะ Beta — ห้าเดือนหลังเปิดตัวเมื่อ 25 มี.ค. 2026 มันคือ fork ของ SQLite ที่ถอดชั้น B-tree ออกแล้วใส่ Prolly Tree (content-addressed B-tree) เข้าไปแทน ผลลัพธ์คือ SQLite ที่ branch, merge, diff, rebase, cherry-pick, reset ได้ และ push/pull/clone/fetch กับ remote ได้แบบ Git

แต่ประโยคที่คนบนอินเทอร์เน็ตหยิบไปถกกันมากที่สุดไม่ใช่เรื่องฐานข้อมูล เป็นเรื่องที่มาของโค้ด Sehn เขียนไว้ตรง ๆ ว่าโปรเจกต์นี้เริ่มจาก “a lark” — เขาต้องการโจทย์จริงไม่ใช่ของเล่นมาทดสอบ Gas Town ซึ่งเป็น agent orchestrator ของ Steve Yegge และคำถามที่เขาตั้งคือ “Could a team of agents pull it off?”

“It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could.”

ทำไมถึงเลือก fork SQLite แทนเขียนใหม่

เหตุผลเชิงวิศวกรรมคมกว่าที่คิด ทีม Dolt อยากได้ Dolt เวอร์ชัน embedded มาหลายปีแล้ว แต่การเขียน storage engine ของ Dolt ใหม่เป็นภาษา C หรือ Rust “เป็นสะพานที่ไกลเกินไป”

การ fork SQLite แก้ปัญหาคนละข้อ — ทุกอย่างเหนือชั้น B-tree ยังเป็น SQLite ของแท้: SQL parser, analyzer, ชั้นติดต่อไฟล์ซิสเต็ม และ test harness Sehn สรุปการแลกเปลี่ยนไว้ว่า ผลิตภัณฑ์ Dolt ตัวอื่นต้องสร้าง SQL engine ขึ้นบน storage ที่มี version control เอง ซึ่งยาก แต่ DoltLite “ได้ SQL engine มาฟรีด้วยราคาของการเขียน storage engine ที่มี version control เป็นภาษา C”

พูดอีกอย่าง: การเลือก fork ไม่ได้แค่ประหยัดแรงเขียน แต่ทำให้ได้ ชุดข้อสอบสำเร็จรูปที่บอกได้ว่าเอเจนต์ทำถูกหรือผิด ซึ่งเป็นเงื่อนไขที่ทำให้งานแบบ 2,000 PR เป็นไปได้ตั้งแต่แรก

Beta แปลว่าอะไร — และตัวเลขที่กางออกมา

Sehn นิยาม Beta ไว้สี่ข้อ พร้อมเลขกำกับทุกข้อ

1. ฟอร์แมตนิ่งแล้ว เขายอมรับตรง ๆ ว่านี่คือคำบ่นอันดับหนึ่งตลอดช่วงพัฒนา — การเปลี่ยนฟอร์แมตที่ไม่ backward-compatible บังคับให้ผู้ใช้ค้างเวอร์ชันเดิมหรือ dump แล้ว import ใหม่เอง กว่าจะถึง Beta เปลี่ยนฟอร์แมตไป 12 ครั้ง ตอนนี้อยู่บนฟอร์แมตปัจจุบันมา 57 รีลีส หรือกว่าสามเดือน และประกาศว่าถ้ามี breaking change ต่อจากนี้จะมีเส้นทาง migration ให้

2. เข้ากันได้กับ SQL ของ SQLite

• ผ่าน sqllogictest 100% (5.8 ล้านคิวรี) — ซึ่งคาดได้ เพราะชั้นคิวรีคือ SQLite ตัวเดิม
• ผ่านชุด TCL acceptance test ของ SQLite 99.46% จาก 892,277 ข้อ เหลือ 4,809 ข้อที่ต่าง และทุกข้อต้องมีเหตุผลกำกับ

สามเหตุผลหลักของข้อที่ต่างนั้นอ่านแล้วเข้าใจดีไซน์ทั้งหมด: ตารางถูก key ด้วย primary key แทน rowid เพื่อรองรับ version control (เทสต์บางข้อไปส่อง rowid ตรง ๆ), DoltLite มี chunk ไม่มี page (เทสต์ที่ส่อง page จึงไม่ผ่าน), และ ไม่มี WAL หรือ journal sidecar (เทสต์กลุ่มนั้นถูกข้าม)

3. version control ครบ — local ครบทั้ง branch/merge/diff/rebase/cherry-pick/reset และ remote ครบทั้ง push/pull/clone/fetch ใช้ DoltHub เป็น sync backend ได้ ประโยคที่ Sehn เขียนเองน่าจะเป็นตัวอย่างการใช้ที่ตรงยุคที่สุด: “Unleash an agent on your SQLite and use dolt_reset('--hard') if it screws something up.”

4. ประสิทธิภาพ — นี่คือส่วนที่ควรอ่านก่อนตัดสินใจ เพราะเขาเรียกมันเองว่า “version control write performance tax” มีรายงานเทียบกับ SQLite บนเบนช์มาร์กสไตล์ sysbench เผยแพร่บน GitHub ทุกคืน และตัวเลขจากรายงานคืนล่าสุดคือ:

กรณี	เทียบกับ SQLite
in-memory — อ่าน	ช้ากว่า 10%
in-memory — เขียน	ช้ากว่า 60%
file-backed — อ่าน	เท่ากัน
file-backed — เขียนแบบ batch	ช้ากว่า 10%
autocommit write เล็ก ๆ	ช้ากว่า 3.1 เท่า

ตัวเลข 3.1 เท่าฟังดูแรง แต่ Sehn กางฐานให้ดูด้วยว่ายังเป็นระดับไมโครวินาที — ~125 μs ใน SQLite เทียบกับ ~400 μs ใน DoltLite บน GitHub runner ตัวเล็ก คำแนะนำของเขาคือ workload ที่แคร์ประสิทธิภาพควรใช้ batched write ให้มากที่สุด

สถานะจริงของโปรเจกต์

ณ วันที่เขียน repo dolthub/doltlite บน GitHub มีดาว 217 ดวง สร้างเมื่อ 13 มี.ค. 2026 และหลังโพสต์ Beta ก็มี v0.50.1 ตามมาแล้วในวันที่ 1 ก.ย. ในรากของ repo มีทั้ง APACHE_LICENSE และ LICENSE.md วางคู่กัน — ซึ่งเป็นรูปแบบเดียวกับ SQLite upstream ที่มีไฟล์ .sqlite-upstream-base กำกับไว้ และมีไฟล์ AGENTS.md อยู่ในรากด้วย ซึ่งตรงกับที่มาของโค้ดพอดี ใครจะเอาไปใช้จริงควรอ่านสองไฟล์นั้นก่อน เพราะโพสต์ประกาศไม่ได้ระบุสัญญาอนุญาตไว้เลย

มุมมอง AI Curator

ปีนี้มีข่าว “AI เขียนซอฟต์แวร์ได้แล้ว” เยอะจนเฝือ สิ่งที่ทำให้ DoltLite ต่างคือมันมาพร้อม เกณฑ์ตัดสินที่ไม่ได้เขียนโดยคนที่อยากให้ผ่าน — 892,277 ข้อของ SQLite ถูกเขียนไว้ก่อนโปรเจกต์นี้เกิด และ 4,809 ข้อที่ไม่ผ่านถูกบังคับให้มีเหตุผลกำกับทีละข้อ นี่คือความแตกต่างชี้ขาดจาก รายงาน METR + Redwood เมื่อ 26 ส.ค. ที่พบว่าเอเจนต์ทุ่มแรงส่วนใหญ่ไปกับการทำ transcript ให้เนียนเพื่อหลอก scorer ที่ไม่มีอยู่จริง — เอเจนต์จะเล่นกับตัววัดเสมอถ้าตัววัดยอมให้เล่น sqllogictest 5.8 ล้านข้อไม่ยอม

บทเรียนที่เอากลับมาใช้ได้เลยจึงไม่ใช่ “ให้เอเจนต์เขียนฐานข้อมูล” แต่คือ เลือกงานที่มี oracle อยู่แล้ว ถ้าทีมคุณจะลองปล่อยเอเจนต์ทำงานใหญ่ อย่าเริ่มจากฟีเจอร์ใหม่ที่ยังไม่มีใครรู้ว่าถูกคืออะไร ให้เริ่มจากงานที่ความถูกต้องถูกนิยามไว้ล่วงหน้าโดยคนอื่น — port ไลบรารีข้ามภาษาที่มี test suite ครบ, implement สเปกที่มี conformance suite, เขียน driver ให้โปรโตคอลที่มีชุดทดสอบมาตรฐาน นั่นคือรูปทรงของงานที่ 2,000 PR จากเอเจนต์แล้วได้ของที่ใช้ได้จริง ส่วนงานที่ตัดสินถูกผิดด้วยรสนิยมยังต้องใช้คนตัดสิน

สำหรับนักพัฒนาไทยโดยเฉพาะสายที่ทำ mobile, edge หรือ desktop app — DoltLite แก้ปัญหาที่เจอกันจริงและแก้ยากมาตลอด คือ การ sync ข้อมูลออฟไลน์แบบรู้ conflict ทุกวันนี้ทีมส่วนใหญ่แก้ด้วยการเขียนชั้น sync เองบน SQLite แล้วสวดภาวนาว่าจะไม่มี write ชนกัน หรือไม่ก็จ่ายให้ Firebase/Supabase การมี branch/merge ระดับฐานข้อมูลใน embedded engine เปลี่ยนโจทย์นั้นทั้งข้อ แต่ต้องชั่งกับภาษีที่เขาประกาศเอง — ถ้าแอปคุณเขียนทีละแถวแบบ autocommit บ่อย ๆ 3.1 เท่าคือของจริง และคำว่า Beta กับดาว 217 ดวงก็แปลว่ายังไม่ถึงเวลาที่จะเอาไปวางใต้ระบบที่ผู้ใช้จ่ายเงิน — เอาไปลองกับ prototype ก่อนคือคำตอบที่ถูกในตอนนี้

แหล่งข่าว

• DoltLite Beta — DoltHub Blog, Tim Sehn, 31 ส.ค. 2026
• dolthub/doltlite — GitHub
• รายงานเปรียบเทียบประสิทธิภาพกับ SQLite (สร้างใหม่ทุกคืน)