Snowflake Summit 2026: ฟีเจอร์ใหม่ที่คนสาย Data ควรรู้
งาน Snowflake Summit 2026 (1–4 มิถุนายน ที่ซานฟรานซิสโก) จบไปพร้อมของใหม่กว่า 26 อย่าง แต่ถ้าให้สรุปเป็นประโยคเดียวสำหรับคนสาย Data คือ — Snowflake กำลังเลิกให้คุณเลือกขนาด warehouse เอง และหันทั้งบริษัทไปเดิมพันกับ “องค์กรที่ขับเคลื่อนด้วย AI agent” ของชิ้นที่กระทบงานประจำวันมากที่สุดชื่อ Adaptive Compute ส่วนของที่เป็นภาพอนาคตคือการยกเครื่องแบรนด์ Cortex ทั้งชุด
สรุปสั้น ๆ: Summit 2026 มีของใหม่ 26+ อย่าง ไฮไลต์คือ (1) Adaptive Compute — compute แบบใหม่ที่เลือกขนาด/จำนวน cluster/จังหวะพักให้เองต่อ query (GA บน AWS 16 มิ.ย. 2026) เร็วขึ้นถึง ~3.5 เท่าในงาน DML หนัก, (2) ยกเครื่อง Cortex — เปลี่ยนชื่อ Snowflake Intelligence เป็น CoWork และ Cortex Code เป็น CoCo, เพิ่ม Deep Research, Cortex Sense (หน่วยความจำองค์กร), และ Grok เข้า Cortex, (3) คุมค่าใช้จ่ายง่ายขึ้น ด้วย resource budget + บิลแบบจ่ายตาม query ทั้งหมดวางทับสถาปัตยกรรมสามชั้นเดิม ไม่ได้รื้อระบบ
ก่อนจะลงรายละเอียด ถ้าใครยังไม่แม่นว่า Snowflake ทำงานยังไง แนะนำอ่าน สถาปัตยกรรม Snowflake 3 ชั้น ประกอบ เพราะของใหม่เกือบทั้งหมดในข่าวนี้ “วางทับ” โครงสามชั้นนั้น ไม่ได้เปลี่ยนหลักการพื้นฐาน
Adaptive Compute — จุดจบของการนั่งเดาไซซ์ warehouse
ของชิ้นที่คนสาย Data ควรสนใจที่สุดคือ Adaptive Compute — บริการ compute แบบใหม่ที่ “รู้จักงาน” (workload-aware) และ เลือกขนาด, จำนวน cluster และจังหวะ suspend/resume ให้เองแบบต่อ query แทนที่คุณต้องมานั่งเลือกเองว่างานนี้ควรใช้ warehouse ขนาด XS หรือ Large, ตั้ง multi-cluster policy ยังไง, ตั้ง auto-suspend กี่วินาที
เดิมทีการเลือกขนาด warehouse เป็นงานที่กินเวลาและเดายาก — เลือกเล็กไปงานช้า เลือกใหญ่ไปเปลืองเงิน และ workload จริงก็ขึ้น ๆ ลง ๆ ตลอดวัน Adaptive Compute แก้ตรงนี้ด้วยการส่งทุก query จากทุก adaptive warehouse ในบัญชีเข้าไปที่ shared pool ก้อนเดียวของบัญชีนั้น แล้วให้ Snowflake ตัดสินใจต่อ query ว่าจะจัด compute ให้เท่าไร และจะรันเลยหรือเข้าคิวก่อน
adaptive warehouse ไม่มี “ขนาดตายตัว” อีกต่อไป แต่ยังคุมทิศทางได้ด้วยปุ่มหลักสองตัว:
- MAX_QUERY_PERFORMANCE_LEVEL — เพดานว่า query เดี่ยว ๆ หนึ่งอันจะกิน compute ได้มากสุดแค่ไหน (ค่าเริ่มต้น XLARGE)
- QUERY_THROUGHPUT_MULTIPLIER — ตัวคูณว่า warehouse จะ burst รองรับงานพร้อมกันได้มากแค่ไหน (ค่าเริ่มต้น 2)
ตัวเลขประสิทธิภาพที่ Snowflake เคลม (อ้างอิงเบนช์มาร์กภายใน) — เร็วขึ้นราว 1.6 เท่า สำหรับงาน analytical, 2.2 เท่า สำหรับงาน operational analytics ที่มีคนใช้พร้อมกันเยอะ ๆ และ 3.5 เท่า สำหรับงาน DML หนัก ๆ อย่างการ transform/ingest ข้อมูล นอกจากนี้ยังเคลมว่าคุ้มค่ากว่า Gen2 Standard Warehouse ราว 1.2 เท่า ด้าน price/performance
จุดที่ต้องเข้าใจให้ถูก: Adaptive Compute ไม่ได้ลบล้างแนวคิด virtual warehouse — มันยังคือ ชั้น compute ที่แยกจาก storage เหมือนเดิม แค่ย้าย “หน้าปัด” ที่คุณต้องหมุนเองไปให้ระบบหมุนแทน หลักการแยก storage/compute ยังอยู่ครบ
เรื่องเงิน: adaptive warehouse ใช้บิลแบบ query-based — จ่ายตาม compute ที่แต่ละ query ใช้จริง ไม่ใช่จ่ายตามเวลาที่ warehouse เปิดค้างไว้ และถ้ามี standard warehouse อยู่แล้ว สามารถแปลงเป็น adaptive ได้แบบ zero-downtime ตอนนี้ Adaptive Compute ขึ้นสถานะ GA บน AWS แล้ว (16 มิ.ย. 2026) โดยจะทยอยขยาย region/cloud อื่นต่อไป
Gen2 warehouse: อีกทางเลือกที่คาดเดาได้
Snowflake ไม่ได้บังคับให้ทุกคนย้ายไป Adaptive ทันที — ยังมี Gen2 Warehouse เป็นอีกเส้นทาง สำหรับงานที่ต้องการประสิทธิภาพ “คาดเดาได้” และคุมเองได้ตามแบบเดิม (เลือกไซซ์เอง, คุม multi-cluster เอง) เหมาะกับ workload ที่นิ่งและเป็น production ที่อยากล็อกพฤติกรรมไว้แน่นอน
พูดง่าย ๆ คือตอนนี้มีสองปรัชญาให้เลือก — Adaptive สำหรับคนที่อยากให้ระบบคิดแทน (workload แกว่ง ไม่อยากจูนเอง) และ Gen2 แบบ manual สำหรับคนที่อยากคุมทุกอย่างเอง (workload นิ่ง ต้องการความแน่นอน) การเข้าใจ micro-partition และวิธีที่ Snowflake หยิบข้อมูล ยังสำคัญกับทั้งสองแบบ เพราะ pruning ที่ดีคือสิ่งที่ทำให้ query ถูกและเร็วไม่ว่าจะรันบน compute แบบไหน
Cortex ยกเครื่อง: จากผู้ช่วยตอบคำถาม สู่ระบบ agent
ฝั่ง AI คือที่ที่ Snowflake เปลี่ยนภาษาการเล่าเรื่องชัดที่สุด งานนี้มาพร้อมการเปลี่ยนชื่อแบรนด์สองตัวใหญ่:
- Snowflake Intelligence → Snowflake CoWork — วางตัวเป็น “personal work agent” ของพนักงานทุกคน ไม่ใช่แค่ตอบคำถามจากข้อมูล แต่ทำงานเชิงรุก เช่น เสนอ insight เอง, ทำ workflow อัตโนมัติ, และสร้างชิ้นงานสำเร็จอย่างไฟล์ PDF/สไลด์ให้เลย
- Cortex Code → CoCo — ผู้ช่วยเขียนโค้ด/งานพัฒนาในระบบนิเวศ Snowflake
ของใหม่ที่น่าสนใจในกลุ่มนี้:
- Deep Research ใน Snowflake CoWork — โหมดสืบค้นสำหรับคำถามปลายเปิดซับซ้อน มันจะ แตกคำถามใหญ่ออกเป็นการสืบค้นย่อยหลายอัน รันขนานกัน ทั้งบนข้อมูลที่มีโครงสร้างและไม่มีโครงสร้าง แล้วสังเคราะห์เป็นรายงานที่ โยงทุกข้อสรุปกลับไปยังแหล่งข้อมูล/query ต้นทางได้ (traceable) — จุดนี้สำคัญเพราะแก้ปัญหา “AI ตอบมั่ว” ด้วยการบังคับให้อ้างอิงกลับได้
- Cortex Sense — “หน่วยความจำองค์กร” ที่เรียนรู้เองว่าองค์กรคุณนิยามธุรกิจยังไง จากประวัติ query, metadata และ dashboard Snowflake เคลมว่าช่วยดันความแม่นของการตอบจากราว 24% เป็น 83%
- Grok (xAI) เข้า Cortex AI แล้ว — เพิ่มเข้าไปในกลุ่มโมเดลที่เรียกใช้ได้ผ่าน Cortex ซึ่งมี Claude, GPT, Gemini, Llama, Mistral และ DeepSeek อยู่แล้ว
จุดที่ควรจำคือ ทั้งหมดนี้ยังทำงานแบบ AI อยู่ “ข้าง ๆ ข้อมูล” ของคุณ — ประมวลผลข้างใน Snowflake ภายใต้ security/governance เดียวกัน ไม่ต้องส่งข้อมูลออกไปที่ API ภายนอก แนวคิดเดียวกับที่ Cortex Search ใช้เป็น backend ของงาน RAG
คุมค่าใช้จ่ายและธีมใหญ่: “agentic enterprise”
เรื่องที่ทีมการเงิน/คนดูแลบิลควรรู้: Snowflake เพิ่ม resource budget ให้ตั้งเพดานค่าใช้จ่ายรายเดือนของบริการอย่าง Cortex Search ได้ และให้ระบบทำ action อัตโนมัติเมื่อใช้เกิน (เช่น ระงับหรือถอนสิทธิ์การใช้งาน) รวมกับบิลแบบ query-based ของ Adaptive Compute แล้ว ทิศทางชัดว่า Snowflake พยายามทำให้ “คุมต้นทุน AI/compute” เป็นเรื่องตั้งค่าได้ ไม่ใช่ลุ้นบิลปลายเดือน
ในภาพใหญ่ ทุกประกาศถูกร้อยด้วยธีมเดียว — “agentic enterprise” หรือองค์กรที่ให้ AI agent ลงมือทำงานจริง Snowflake หนุนด้วยเงินลงทุนโครงสร้างพื้นฐานราว 6 พันล้านดอลลาร์ และ กระชับความร่วมมือกับ Anthropic จนวางโมเดล Claude ไว้เป็นแกนของทั้ง CoWork และ CoCo พร้อมของฝั่ง data engineering อย่าง Iceberg v3, Openflow และเรื่อง identity/governance ของ agent
ธีมนี้บอกทิศทางอาชีพกลาย ๆ: Snowflake กำลังผลักงาน “จูน infra ด้วยมือ” ให้เป็นงานของระบบ แล้วยกความสำคัญไปที่ “ออกแบบ context, semantic และ governance ให้ agent ทำงานถูก” แทน
วิเคราะห์: มันแปลว่าอะไรกับเรา
กระทบคนสาย Data / นักพัฒนายังไง
ทักษะ “จูนขนาด warehouse ด้วยมือ” กำลังจะมีค่าน้อยลง — ไม่ใช่หายไปทันที แต่ Adaptive Compute ส่งสัญญาณชัดว่างานนั้นระบบทำแทนได้ดีขึ้นเรื่อย ๆ สิ่งที่ ยังมีค่าและมีค่ามากขึ้น คือความเข้าใจว่า query ของคุณแพงเพราะอะไร (pruning ดีไหม, join บวมไหม, เขียน SQL ให้ optimizer ทำงานง่ายหรือเปล่า) เพราะบิลแบบ query-based จะทำให้ “query ห่วย = จ่ายแพง” ชัดกว่าเดิม
อีกด้านคือทักษะสาย AI/agent บนข้อมูลองค์กร (semantic model, Cortex Analyst/Search, การออกแบบให้ผลลัพธ์ traceable) กำลังกลายเป็นทักษะกระแสหลักของสาย Data ไม่ใช่ของเสริมอีกต่อไป
กระทบคนไทย / องค์กรไทยโดยเฉพาะ
- ต้นทุนคาดเดาง่ายขึ้น = ดีกับ SME ไทย — องค์กรเล็กที่ไม่มีทีม data engineer คอยจูน warehouse ทั้งวัน ได้ประโยชน์จาก Adaptive Compute มากที่สุด เพราะระบบจูนให้ และ resource budget ช่วยกันบิลบานปลาย
- PDPA / data residency ยังเป็นโจทย์ที่ต้องตรวจเอง — ฟีเจอร์ AI ที่ประมวลผล “ข้าง ๆ ข้อมูล” ช่วยเรื่องข้อมูลไม่ออกนอกระบบก็จริง แต่ Adaptive Compute เพิ่ง GA บน AWS และทยอยขยาย region — องค์กรที่ต้องการให้ข้อมูลอยู่ใน region ที่กำหนด (หรือใกล้ไทยที่สุด) ต้องเช็ก availability ของแต่ละฟีเจอร์ต่อ region เองก่อนใช้จริง
- งานภาษาไทยได้อานิสงส์ — โมเดลใน Cortex ที่หลากหลายขึ้น (รวมความสามารถแปล/ประมวลผลข้อความยาว) เปิดทางทำงาน NLP ภาษาไทยบนข้อมูลองค์กรได้โดยไม่ต้องต่อ API ภายนอก แต่ยังต้องทดสอบคุณภาพภาษาไทยเป็นเคส ๆ ไป อย่าเชื่อสเปกอย่างเดียว
ควรเตรียม/ปรับตัวอะไร
- ทดลอง Adaptive Compute กับ workload ที่แกว่ง — ถ้าใช้ AWS อยู่แล้ว ลองแปลง standard warehouse สัก non-prod ตัว (แปลงได้แบบ zero-downtime) วัดผลก่อน แล้วค่อยตัดสินใจว่าจะย้ายทั้งบัญชีไหม
- ตั้ง resource budget ตั้งแต่วันนี้ — โดยเฉพาะถ้าเริ่มเปิดใช้ Cortex/AI features กันเซอร์ไพรส์ปลายเดือน
- ลงทุนกับทักษะที่ระบบแทนไม่ได้ — อ่าน query profile เป็น, ออกแบบ semantic model, เข้าใจ governance/identity ของ agent มากกว่าท่องขนาด warehouse
- อย่าเพิ่งรื้อของเดิม — ทุกอย่างวางทับสถาปัตยกรรมสามชั้นเดิม ใครแม่นพื้นฐาน (storage/compute/services) อยู่แล้วปรับตัวได้เร็วที่สุด
โดยรวม Summit 2026 ไม่ใช่การเปิดตัว Snowflake เวอร์ชันใหม่ที่ต้องเรียนใหม่หมด แต่เป็นการ “ยกงานน่าเบื่อออกจากมือคน” (เลือกไซซ์ compute) แล้วดันความสำคัญไปที่การให้ AI agent ทำงานบนข้อมูลที่ปกครองได้ สำหรับคนไทย ข่าวดีคือกำแพงเรื่องต้นทุนและการดูแลระบบเตี้ยลง ส่วนการบ้านที่เหลือ — ความเข้าใจพื้นฐานและการคุม data residency ให้ตรงกฎ — ยังเป็นของเราที่ต้องทำเอง
