Datastores

คำถาม "ควรใช้ฐานข้อมูลอะไร" ตอบไม่ได้ถ้ายังไม่มี access pattern table บทนี้ไม่ตอบคำถามนั้น — บทนี้บอกว่า แต่ละตระกูลคืออะไร เก่งอะไร เก่งเพราะกลไกอะไร และล้มแบบไหน เพื่อให้ตอนคุณกลับไปดู pattern table ในบทที่ 14 คุณเลือกได้เอง

และเพราะปี 2026 มีของใหม่ที่ทีมคุณจะโดนถามในห้องประชุมแน่ๆ ("ทำไมเราไม่ใช้ ClickHouse", "TigerBeetle มันดีจริงไหม", "Iceberg คือ database หรือเปล่า") บทนี้จึงมีหัวข้อที่ไล่ของที่กำลังเป็นกระแสทีละตัว พร้อมกลไกที่ทำให้มันเก่งและราคาที่ต้องจ่าย ไม่ใช่แค่ชื่อกับคำโฆษณา

3 แกนที่อธิบายทุก datastore#

ก่อนจะจำชื่อ ให้จำ 3 แกนนี้ก่อน — เกือบทุกคุณสมบัติของ datastore เป็นผลพวงจาก 3 ข้อนี้ และถ้าคุณอ่าน datastore ใหม่ที่ยังไม่เคยเห็นด้วย 3 แกนนี้ คุณจะเดาจุดแข็งกับจุดพังของมันได้เองก่อนอ่าน benchmark

รายละเอียดของ B-tree กับ LSM-tree อยู่ในบทที่ 14 — บทนี้จะใช้คำพวกนี้ต่อโดยไม่อธิบายซ้ำ

ตระกูลของ datastore#

Datastore ที่เป็นกระแสในปี 2026#

หัวข้อนี้ไม่ใช่รายการ "ของที่ควรใช้" — เป็นรายการ "ของที่คุณจะโดนถามถึง และควรตอบได้ว่ามันเก่งเพราะอะไร" สังเกตว่าเกือบทุกตัวในตารางนี้ไม่ได้ชนะด้วยการเป็นฐานข้อมูลที่ดีกว่าในทุกด้าน แต่ชนะด้วยการตัดความสามารถบางอย่างทิ้งอย่างจงใจ เพื่อแลกกับความเก่งเฉพาะทางที่ชัดมาก นั่นคือสิ่งที่คุณควรมองหาเวลาประเมินของใหม่

ClickHouse — OLAP ที่ออกแบบให้ scan ไม่ใช่ seek#

กลไกที่ทำให้มันเก่ง — ไม่ใช่เวทมนตร์ มันคือ 3 อย่างที่ทำงานทับกัน

1. Sparse primary index — ClickHouse ไม่ทำ index ทีละแถว มันแบ่งข้อมูลเป็น granule ขนาด 8,192 แถวโดยค่าเริ่มต้น แล้วเก็บ index 1 entry ต่อ granule ผลคือ index ของตารางระดับหลายล้านแถวมีขนาดเล็กพอที่จะโหลดเข้า memory ได้ทั้งก้อน query จึงทำ binary search บน index ใน memory เพื่อตัด granule ที่ไม่เกี่ยวออกก่อนแตะดิสก์ — เอกสารของ ClickHouse ยกตัวอย่างตาราง 8.87 ล้านแถวที่ได้ประมาณ 1,083 granule และ primary index ขนาดระดับร้อยกิโลไบต์
2. Columnar + compression codec เฉพาะชนิด — คอลัมน์ timestamp ที่เรียงกันใช้ delta encoding, คอลัมน์ enum ใช้ dictionary, แล้วทับด้วย LZ4 หรือ ZSTD อีกชั้น
3. MergeTree — write เข้ามาเป็น part ที่ immutable แล้วมี background merge รวม part (เป็น LSM ในรูปแบบของ column store) → write path เป็น sequential ล้วน

ราคาที่จ่าย และนี่คือส่วนที่คนข้ามบ่อยที่สุด

• ALTER TABLE ... UPDATE/DELETE คือ mutation ไม่ใช่ UPDATE แบบ OLTP — มันเขียน part ใหม่ทั้งก้อน และห้ามแก้คอลัมน์ที่อยู่ใน primary key หรือ sorting key เอกสารของ ClickHouse เองแนะนำให้ใช้ deduplication หรือ lightweight delete แทนการ mutate บ่อยๆ
• ไม่มี transaction ข้ามตารางแบบที่คุณใช้ป้องกัน invariant เรื่องเงิน
• ORDER BY key ของตารางคือ design เหมือน partition key ของ Cassandra — เลือกผิดแล้ว query ที่ไม่ตรงกับมันจะกลาย full scan

ในบริบท fintech ควรวางมันไว้ตรงไหน — fraud analytics, product analytics, observability, และงาน reconciliation ที่ต้อง scan ธุรกรรมทั้งวัน ไม่ใช่ ledger และไม่ใช่ที่ที่คุณตัดสินใจหักเงิน — ตรงนั้นดูบทที่ 16

DuckDB และ DuckLake — analytics ที่ไม่ต้องมี cluster#

กลไก — DuckDB เป็น analytical database ที่รัน ในโปรเซสเดียวกับแอปของคุณ (คนมักเรียกว่า "SQLite ของฝั่ง analytics") ไม่มี server ไม่มี port ไม่มี daemon แต่ข้างในเป็น columnar + vectorized execution เต็มรูปแบบ และมันอ่าน Parquet, CSV, JSON รวมถึงตาราง Iceberg บน object storage ได้โดยตรง โดยไม่ต้อง import เข้ามาก่อน

จุดแข็งที่จับต้องได้

• งาน reconciliation ปลายวันที่เคยต้องยก cluster ขึ้นมา กลายเป็น job เดียวในคอนเทนเนอร์เดียว
• Data engineer ทดสอบ query บนข้อมูลจริงบนเครื่องตัวเองได้ ไม่ต้องรอ warehouse quota
• ใช้เป็น query engine ฝังใน service เพื่อทำ aggregation บนไฟล์ที่ดึงมาจาก S3

ราคาที่จ่าย — โปรเซสเดียว ไม่ใช่ multi-user database server, ไม่มี concurrency control สำหรับผู้เขียนหลายคนพร้อมกันแบบ Postgres, และขนาดข้อมูลที่ทำงานได้ผูกกับเครื่อง 1 เครื่อง (แม้จะไปได้ไกลกว่าที่คนคิดมาก)

DuckLake คือส่วนขยายที่เก็บ metadata ของ lakehouse ไว้ใน SQL database แทนที่จะเป็น ไฟล์ catalog บน object storage — ผลคือ metadata lookup และ partition pruning เร็วขึ้น และได้ multi-table transaction กับ time travel มาในอินเทอร์เฟซ SQL เดียว — ducklake.select · DuckDB Iceberg extension

Apache Iceberg — table format ที่แยก storage ออกจาก engine#

นี่คือของที่คนสับสนมากที่สุดในตารางนี้ Iceberg ไม่ใช่ database มันคือ สเปกว่าไฟล์ Parquet กองหนึ่งบน object storage จะถูกเรียกว่า "ตาราง" ได้ยังไง — มี manifest บอกว่าไฟล์ไหนอยู่ในตาราง, มี snapshot บอกว่าสถานะ ณ เวลาหนึ่งคืออะไร, และมี schema evolution ที่ไม่ต้องเขียนข้อมูลใหม่

จุดแข็งที่จับต้องได้ — เป็นเรื่อง lock-in มากกว่าเรื่องความเร็ว

• ตารางเดียวกันถูกอ่าน/เขียนได้จากหลาย engine (Spark, Trino, Flink, DuckDB, ClickHouse, Snowflake, Databricks) → คุณเปลี่ยน query engine ได้โดยไม่ต้องย้ายข้อมูล ซึ่งเป็น exit path ที่ประเมินค่าเป็นตัวเงินได้ในการเจรจากับ vendor
• Snapshot ทำให้ time travel และ rollback เป็นของที่มีอยู่แล้ว ไม่ต้องสร้างเอง — มีค่ามากตอนตรวจสอบย้อนหลังและตอน pipeline เขียนข้อมูลผิด
• Optimistic concurrency + serializable isolation ตามสเปก โดย reader ไม่ต้องถือ lock

สถานะสเปก (ยืนยันจากสเปกโดยตรง) — เวอร์ชัน 1, 2 และ 3 เสร็จและถูกรับรองโดยชุมชนแล้ว ส่วนเวอร์ชัน 4 ยังอยู่ระหว่างพัฒนาและยังไม่ถูกรับรองอย่างเป็นทางการ

ราคาที่จ่าย — ต้องมี catalog (ตัวที่บอกว่าตารางล่าสุดอยู่ที่ metadata ไฟล์ไหน), ต้องมี maintenance job สำหรับ compaction และลบ snapshot เก่า และถ้า pipeline เขียนไฟล์เล็กๆ ถี่ๆ คุณจะเจอ small-file problem ที่ทำให้ query ช้าลงเรื่อยๆ

ฝั่ง AWS มี S3 Tables ที่ทำ Iceberg ให้เป็น storage primitive ที่จัดการ compaction ให้ ซึ่งลดงาน maintenance ข้างต้นไปได้ส่วนหนึ่ง — แลกกับการผูกกับ managed service ของเจ้าเดียว

TigerBeetle — OLTP ที่ตัดทุกอย่างทิ้งเพื่อ debit/credit#

ตัวนี้เกี่ยวกับงานที่พวกเราทำโดยตรงที่สุดในรายการทั้งหมด จึงควรเข้าใจให้ละเอียดกว่าตัวอื่น

กลไกที่ทำให้มันเก่ง — จุดสำคัญคือเรื่อง interface ไม่ใช่เรื่อง engine

ฐานข้อมูลทั่วไปให้ business logic อยู่ที่แอป แล้วแอปต้องถือ lock ข้ามเน็ตเวิร์ก ระหว่างที่คิดว่าจะหักเงินเท่าไหร่ — พอ contention สูง (บัญชีร้อนไม่กี่บัญชีอยู่ในธุรกรรมส่วนใหญ่) ทั้ง latency และ throughput พังพร้อมกันตาม Little's Law TigerBeetle ย้าย debit/credit เข้าไปอยู่ในฐานข้อมูลเอง จึงไม่ต้องมี lock ข้ามเน็ตเวิร์กเลย

เมื่อ interface ถูกแล้ว วิศวกรรมที่เหลือถึงจะมีผล — และของพวกนี้เป็นรูปธรรมมาก

ราคาที่จ่าย และมันแพงจริง

• Schema ตายตัว — เก็บได้แค่ Account กับ Transfer ไม่มีชื่อลูกค้า ไม่มีสถานะ KYC ไม่มี metadata ของธุรกรรม แปลว่าคุณยังต้องมี Postgres คู่ไปด้วยเสมอ และคุณเพิ่งสร้างปัญหา dual-write ให้ตัวเอง (วิธีแก้อยู่ในบทที่ 16)
• Single-threaded และ single leader โดยตั้งใจ — เอกสารระบุตรงๆ ว่าการเพิ่ม node เพิ่มความน่าเชื่อถือ ไม่ใช่ throughput เหตุผลคือการ shard ฐานข้อมูลการเงินทำได้ยาก เพราะบัญชีร้อนไม่กี่บัญชีจะทำให้ shard นั้นเป็นคอขวดอยู่ดี
• ไม่มี SQL, ไม่มี ad-hoc query, เครื่องมือ ops รอบตัวยังน้อยกว่า Postgres มาก
• ทีมต้องเรียนรู้ data model แบบ debit/credit ให้แน่นก่อน ไม่ใช่หลัง

Aurora DSQL และตระกูล distributed SQL#

สัญญาของหมวดนี้ — SQL ที่ scale ตามแนวนอนและทน node/AZ ตายได้ โดยที่คุณยังเขียน SQL เหมือนเดิม Aurora DSQL (GA เมื่อ 27 พ.ค. 2025) เป็นตัวที่ผลักไปไกลสุดฝั่ง serverless: active-active หลาย region พร้อม strong consistency โดยไม่มี node ให้คุณดูแลเลย

แต่ "PostgreSQL-compatible" ไม่ได้แปลว่า drop-in และนี่คือบทเรียนที่ใช้ได้กับทั้งหมวด ข้อจำกัดต่อไปนี้มาจากเอกสารของ AWS โดยตรง

วิธีอ่านข้อจำกัดพวกนี้ให้เป็นประโยชน์ — มันไม่ใช่ "ข้อบกพร่อง" แต่คือราคาของ active-active ข้าม region ที่ต้องมีคนจ่าย ระบบกระจายที่ไม่ต้องการ coordinator กลางจะไม่มีทางให้ FK แบบที่ตรวจข้ามทั้งคลัสเตอร์ได้ฟรี ทางเลือกอื่นในหมวดนี้ (CockroachDB, TiDB, Spanner) เลือกจ่ายราคาคนละจุดกัน — ตัวที่ให้ FK มักจ่ายเป็น latency ต่อ transaction แทน

Valkey กับ Redis — เรื่อง license ที่กลายเป็นเรื่อง architecture#

ลำดับเหตุการณ์ที่ควรรู้ เพราะมันกระทบว่า managed service ที่คุณใช้จะเป็นตัวไหนในอีก 3 ปี

• มี.ค. 2024 — Redis เปลี่ยนจาก BSD ไปเป็น license แบบ source-available (RSALv2 / SSPLv1)
• มี.ค. 2024 — Linux Foundation ประกาศ Valkey ซึ่ง fork มาจาก Redis 7.2.4 ภายใต้ BSD-3 โดยมีผู้ร่วมก่อตั้งเป็นผู้ให้บริการคลาวด์รายใหญ่หลายเจ้า
• พ.ค. 2025 — Redis เพิ่มทางเลือก AGPLv3 ให้ Redis 8 (ประกาศจาก Redis)

ทำไม engineer ต้องสนใจ — เพราะ managed service คือสิ่งที่คุณใช้จริง ไม่ใช่ซอร์สโค้ด เมื่อผู้ให้บริการคลาวด์ย้ายค่าเริ่มต้นไปทาง Valkey สิ่งที่ตามมาคือ roadmap ของฟีเจอร์, โครงสร้างราคา, และชุด module ที่ใช้ได้ เดินแยกทางกันตั้งแต่จุด fork

สิ่งที่ต้องตรวจก่อนเลือกข้าง (เป็นรูปธรรม)

• คุณใช้ module อะไรอยู่ (search, JSON, time-series, bloom) และมันมีในฝั่งที่คุณจะไปไหม
• client library ที่ทีมใช้ ประกาศรองรับเวอร์ชันไหนของฝั่งไหน
• ถ้าเป็นงานที่ regulated ทีม legal ต้องรู้ว่าคุณใช้ AGPLv3 หรือ BSD-3 — นี่เป็นคำถามที่ต้องส่งให้เจ้าของด้าน legal ตอบ ไม่ใช่ engineer ตัดสินเอง

Postgres ที่กลืนงานของ store อื่นไปเรื่อยๆ#

กระแสที่แรงที่สุดในปี 2026 อาจไม่ใช่ฐานข้อมูลใหม่เลย แต่คือการที่ Postgres ทำงานที่เคยต้องใช้ store แยกได้ "ดีพอ" มากขึ้นทุกปี จนเกณฑ์ที่จะเพิ่ม store ใหม่สูงขึ้นเรื่อยๆ

ฝั่งตัวเครื่องยนต์เองก็ขยับ — PostgreSQL 18 เพิ่มระบบ asynchronous I/O (เลือก method ได้ทั้งแบบ worker และ io_uring), uuidv7() ที่ให้ id เรียงตามเวลาจึงเป็นมิตรกับ B-tree index มากกว่า UUIDv4, virtual generated column, skip scan สำหรับ B-tree และ OAuth 2.0 authentication

Object-storage-native — เมื่อ S3 กลายเป็นดิสก์หลัก#

แนวคิด — แทนที่จะเก็บ state บนดิสก์ของ node แล้ว replicate ข้าม AZ เอง ระบบกลุ่มนี้ยก durability ทั้งหมดให้ object storage แล้วใช้ NVMe กับ RAM เป็น cache เท่านั้น node จึงกลายเป็นของที่ทิ้งได้จริง ไม่มี state ที่ต้องกู้

จุดแข็งที่จับต้องได้

• ไม่มีค่า replication ข้าม AZ เพราะ object storage จัดการ durability ให้แล้วในราคาของมัน
• scale ลงเหลือเกือบศูนย์ได้ — workload ที่ query เป็นช่วงๆ ไม่ต้องจ่ายค่า cluster ที่เปิดค้างไว้
• ไม่มี state ที่ต้อง rebalance ตอนเพิ่ม/ลด node ทำให้ operational model ง่ายลงมาก
• ต้นทุนต่อ GB ของ object storage ต่ำกว่า memory มาก — เหมาะกับข้อมูล cold ที่ต้องค้นได้เป็นครั้งคราว (ตัวเลขเปรียบเทียบที่ vendor เผยแพร่เป็น illustrative ให้ยืนยันกับ pricing ของ region คุณเอง)

ราคาที่จ่าย — latency พื้นของ object storage อยู่ระดับ 10 มิลลิวินาทีขึ้นไปต่อ request ระบบกลุ่มนี้จึงต้องมี cache ทุกชั้นและ p99 จะแย่ลงชัดเจนตอน cache miss ไม่เหมาะกับ write ที่ต้อง ack ในระดับมิลลิวินาทีเดียว หรือ read ที่ต้องนิ่งทุก request

ตัวอย่างที่อ่านได้จริง — turbopuffer (search + vector), SlateDB (LSM ที่เขียนลง object storage ตรง), Quickwit (log search) และฝั่ง streaming ก็มี WarpStream ที่ทำ Kafka protocol บน object storage ล้วน (Confluent ประกาศเข้าซื้อ) — รูปแบบเดียวกันโผล่ในหลายหมวดพร้อมกัน นั่นคือสัญญาณว่ามันเป็นแนวสถาปัตยกรรม ไม่ใช่ผลิตภัณฑ์เดี่ยว

วิธีประเมิน datastore ที่กำลังมาแรง#

ของในหัวข้อที่แล้วจะเปลี่ยนไปในอีก 2 ปี แต่วิธีประเมินไม่เปลี่ยน ใช้ตารางนี้กับ datastore ตัวไหนก็ได้ รวมถึงตัวที่ยังไม่เกิด

Search index — derived เสมอ ไม่เคยเป็น authoritative#

• Populate จากฐานข้อมูลผ่าน CDC หรือ outbox เพื่อให้สร้างใหม่จากศูนย์ได้เสมอ
• ตั้งงบเวลาสำหรับ full reindex — คุณจะต้องทำทุกครั้งที่แก้ mapping
• คาดหวัง near-real-time (~1 s refresh) และออกแบบ UX ให้รองรับ ("เอกสารของคุณกำลังถูกจัดทำดัชนี")
• คืนแค่ id จาก search แล้วไปดึงรายละเอียดจาก source of truth ป้องกันการแสดงข้อมูลเก่าและป้องกัน PII ค้างใน index

ตัวเลือกในหมวดนี้ปี 2026 กว้างขึ้นกว่าเดิม: Elasticsearch กับ OpenSearch เป็นสาย cluster เต็มรูปแบบ, ส่วน Quickwit และ turbopuffer เป็นสาย object-storage-native ที่แลก latency พื้น กับต้นทุนที่ต่ำลงมากสำหรับข้อมูล cold — เลือกจากรูปร่างของ query ไม่ใช่จากความใหม่

Object storage — ที่ที่ข้อมูลรั่วบ่อยที่สุด#

Upload flow ที่ถูก

1. Client -> API:  POST /v1/documents  (ประกาศ type, ขนาด, purpose)
2. API:            ตรวจสิทธิ์, สร้าง record (status = AWAITING_UPLOAD),
                   คืน pre-signed PUT URL ที่ผูก key + content-length + หมดอายุ 5 นาที
3. Client -> S3:   PUT byte ตรงเข้า object storage
4. S3 -> API:      event notification ว่า object มาถึง
5. API:            อ่าน metadata จริง (magic bytes, ขนาด), scan, แล้ว
                   set status = READY หรือ REJECTED
--> ห้ามเชื่อขั้นที่ 1 เลย ทุกอย่างต้องยืนยันที่ขั้นที่ 5

Geo / spatial#

ข่าวดีของปี 2026 คือฝั่ง analytics ตามมาแล้ว — Iceberg spec v3 เพิ่มชนิด geometry และ geography เข้ามาในตัว แปลว่าข้อมูลเชิงพื้นที่บน lakehouse ไม่ต้องเก็บเป็น WKT string แล้วแปลงเองอีกต่อไป

รายละเอียดการออกแบบ nearby search อยู่ในบทที่ 19 · อ้างอิง: H3 — Uber's hexagonal hierarchical spatial index

Time-series — ระวัง cardinality#

ห้าม:  http_requests_total{user_id="u_918273", path="/v1/transfers/trf_01J9XYZ"}
       --> 1 ล้านผู้ใช้ x 500,000 transfer = time series หลายพันล้านเส้น

ควร:  http_requests_total{route="/v1/transfers/:id", method="POST", status="201"}
       --> route ที่ normalize แล้ว x method x status = หลักร้อยเส้น

ทำไม cardinality ถึงฆ่าระบบได้ — แต่ละชุด label ที่ไม่ซ้ำกันคือ time series 1 เส้น ที่ต้องมี index, มี memory ค้างไว้สำหรับ chunk ล่าสุด และมีต้นทุนตอน query ที่ต้องรวมเส้นเหล่านี้ การเพิ่ม label 1 ตัวที่มี 10,000 ค่าเป็นการคูณ จำนวนเส้นทั้งหมดด้วย 10,000 ไม่ใช่บวก นี่คือเหตุผลที่มันพังแบบฉับพลันไม่ใช่ค่อยๆ ช้าลง

ถ้าต้องเก็บ metric ระยะยาวหลายทีมรวมกัน ฝั่ง long-term storage อย่าง Grafana Mimir หรือ Thanos ช่วยเรื่อง retention และ multi-tenant ได้ — แต่ไม่ได้แก้ปัญหา cardinality ให้ ปัญหานั้นแก้ได้ที่ตอนตั้งชื่อ label เท่านั้น

Vector store — pgvector ก่อน แล้วค่อยคิดเรื่องอื่น#

ใช้เมื่อทำ semantic search หรือ retrieval สำหรับฟีเจอร์ AI เท่านั้น ถ้า query ของคุณเป็นการหาคำที่ตรงกัน search index ธรรมดายังเป็นคำตอบที่ถูกกว่าและอธิบายผลลัพธ์ได้ง่ายกว่า

ลำดับการตัดสินใจที่เสียหายน้อยที่สุด

1. เริ่มที่ pgvector ใน Postgres ที่คุณมีอยู่แล้ว — ได้ transaction, backup, สิทธิ์ และ join กับข้อมูลจริงมาฟรีทั้งหมด
2. เลือก index ให้ตรงกับงาน — HNSW ให้ recall กับ latency ที่ดีกว่าแต่กิน memory และสร้างช้ากว่า ส่วน IVFFlat สร้างเร็วและกิน memory น้อยกว่าแต่ต้องมีข้อมูลก่อนถึงจะ train ได้
3. วัด recall ไม่ใช่แค่ latency — vector index เป็น approximate ระบบที่ตอบเร็วแต่พลาดผลลัพธ์ที่ถูกต้องคือระบบที่ผิด และตัวเลขนี้ไม่โผล่ใน dashboard latency
4. แยกออกเป็น vector database ต่างหากเมื่อวัดแล้วว่าไม่ไหว — ปกติคือเรื่องจำนวน vector ระดับหลายสิบล้านขึ้นไป, ความต้องการ filter ซับซ้อนพร้อม ANN, หรือการกระจายหลาย region ตัวเลือกในหมวดนี้เช่น Qdrant, Milvus, turbopuffer

ตารางสรุป: จับคู่ pattern กับ store#

Checklist ก่อนตัดสินใจเพิ่มหรือเปลี่ยน datastore#

• มี access pattern table จากบทที่ 14 แล้ว ไม่ใช่เริ่มจากชื่อผลิตภัณฑ์
• อธิบายได้ว่าตัวที่เลือกอยู่ตรงไหนของ 3 แกน และทำไมแกนนั้นตรงกับ pattern ของเรา
• เขียน ราคาที่ต้องจ่าย ของตัวเลือกนั้นไว้ใน design doc อย่างน้อย 3 ข้อ
• วัดแล้วว่า store ที่มีอยู่ทำไม่ได้จริง พร้อมตัวเลขและวันที่ที่วัด
• ถ้าเป็น derived store: มีเส้นทาง rebuild จาก source of truth และเคยทดสอบ rebuild แล้ว
• ถ้าเป็น derived store: มีเส้นทางลบข้อมูลส่วนบุคคล และพิสูจน์ได้ว่าลบแล้ว
• มีคนในทีมอย่างน้อย 2 คนที่ operate ตัวนี้ได้ หรือมี managed service พร้อม SLA ที่อ่านแล้ว
• เคยซ้อม restore จาก backup ลงระบบเปล่าและจับเวลาไว้
• license ผ่านการตรวจจากเจ้าของด้าน legal แล้ว พร้อมชื่อและวันที่
• มีทางออก — export เป็น format มาตรฐานได้ และประเมินเวลาไว้แล้ว
• มีแผนว่าจะปลด store เดิมเมื่อไหร่ หรือระบุชัดว่าจะอยู่คู่กันถาวรและใครดูแล