21 ส.ค. 2568·2 นาที
ทำไม SQLite ถึงอยู่ทุกที่: ฐานข้อมูลแบบฝังที่ชนะใจ
SQLite ขับเคลื่อนแอป เบราว์เซอร์ และอุปกรณ์ทั่วโลก เรียนรู้ว่าทำไมการออกแบบแบบฝังและไร้เซิร์ฟเวอร์ของมันถึงได้เปรียบ: เรียบง่าย เชื่อถือได้ รวดเร็ว พกพาได้ — และข้อจำกัดที่ควรรู้
SQLite ขับเคลื่อนแอป เบราว์เซอร์ และอุปกรณ์ทั่วโลก เรียนรู้ว่าทำไมการออกแบบแบบฝังและไร้เซิร์ฟเวอร์ของมันถึงได้เปรียบ: เรียบง่าย เชื่อถือได้ รวดเร็ว พกพาได้ — และข้อจำกัดที่ควรรู้
SQLite เป็นเอนจิ้นฐานข้อมูลขนาดเล็กที่มาในรูปแบบไลบรารีที่แอปของคุณลิงก์เข้าไป—เป็นฟีเจอร์ที่คุณใส่ลงในแอป ไม่ใช่บริการที่ต้องรันแยกต่างหาก แทนที่จะส่งคำขอผ่านเครือข่ายไปยังเครื่องฐานข้อมูลอื่น แอปของคุณจะอ่านและเขียนไปยังไฟล์ฐานข้อมูลเดียว (มักเป็น app.db) บนดิสก์โดยตรง
ความคิดที่ว่า “มันคือแค่ไฟล์” เป็นส่วนสำคัญของเสน่ห์ ไฟล์ฐานข้อมูลมีตาราง ดัชนี และข้อมูล และ SQLite จัดการส่วนยากๆ ให้—คำสั่ง SQL ข้อจำกัด และ ธุรกรรมแบบ ACID—เบื้องหลัง
กับฐานข้อมูลแบบ client-server (คิดถึง PostgreSQL หรือ MySQL) คุณมักจะ:
กับ SQLite ฐานข้อมูลจะรัน ภายใน กระบวนการแอปของคุณ ไม่มีเซิร์ฟเวอร์แยกให้ติดตั้ง เริ่มต้น หรือดูแล แอปของคุณเรียก API ของ SQLite และ SQLite อ่าน/เขียนไฟล์ท้องถิ่นโดยตรง
คนมักอธิบาย SQLite ว่า “serverless” ซึ่งไม่ได้หมายความว่ามันอยู่บนคลาวด์โดยไม่มีเซิร์ฟเวอร์—แต่หมายความว่า คุณไม่ต้องจัดการโปรเซสเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก
SQLite ปรากฏตัวอย่างเงียบๆ ในซอฟต์แวร์หลายชนิดเพราะมันง่ายต่อการส่งมอบและเชื่อถือได้:
หลายผลิตภัณฑ์เลือก SQLite เพราะเป็นค่าเริ่มต้นที่ตรงไปตรงมา: เร็ว มั่นคง และไม่ต้องตั้งค่า
SQLite เหมาะสำหรับแอปผู้ใช้คนเดียว อุปกรณ์ฝังตัว โปรโตไทป์ที่กลายเป็นผลิตภัณฑ์จริง และบริการที่มีการเขียนพร้อมกันในระดับปานกลาง แต่ไม่ใช่คำตอบสำหรับทุกปัญหาการขยายตัว—โดยเฉพาะเมื่อหลายเครื่องต้องเขียนฐานข้อมูลเดียวกันพร้อมกัน
สรุป: SQLite ไม่ได้ “เล็ก” ในความสามารถ แต่เล็กในภาระการปฏิบัติการ นั่นคือเหตุผลที่คนยังคงเลือกใช้
สองคำที่ฟังดูเป็นคำฮิต: แบบฝัง (embedded) และ ไร้เซิร์ฟเวอร์ (serverless) ในบริบทของ SQLite ทั้งสองมีความหมายเฉพาะและปฏิบัติได้จริง
SQLite ไม่ใช่สิ่งที่คุณ “รัน” แบบแบ็กกราวด์เหมือน PostgreSQL หรือ MySQL มันเป็น ไลบรารีซอฟต์แวร์ ที่แอปของคุณลิงก์และเรียกใช้โดยตรง
เมื่อแอปของคุณต้องอ่านหรือเขียนข้อมูล มันจะเรียกฟังก์ชันของ SQLite ภายในโปรเซสเดียวกัน ไม่มีเดมอนฐานข้อมูลแยกให้ต้องสตาร์ท มอนิเตอร์ แพต หรือรีสตาร์ท แอปและเอนจิ้นฐานข้อมูลอยู่ร่วมกัน
“Serverless” ของ SQLite ไม่ได้เหมือนกับบริการ “serverless” ที่ผู้ให้บริการคลาวด์โฆษณา
กับฐานข้อมูล client-server โค้ดของคุณส่ง SQL ผ่าน TCP ไปยังโปรเซสอื่น แต่กับ SQLite โค้ดของคุณเรียก SQL ผ่านการเรียกไลบรารี (มักผ่าน binding ของภาษา) และ SQLite อ่าน/เขียนไฟล์ฐานข้อมูลบนดิสก์
ผลลัพธ์: ไม่มีการท่องเครือข่าย, ไม่ต้องปรับ connection pool, และมีโหมดล้มเหลวน้อยลง (เช่น “เชื่อมต่อกับโฮสต์ DB ไม่ได้”)
สำหรับหลายผลิตภัณฑ์ “แบบฝัง + ไร้เซิร์ฟเวอร์” แปลว่าองค์ประกอบน้อยลง:
ความเรียบง่ายนี้เป็นเหตุผลสำคัญที่ SQLite ปรากฏตัวทั่วไป—แม้ในกรณีที่ทีมอาจเลือกบางอย่างที่หนักกว่าได้
ข้อได้เปรียบที่ถูกมองข้ามที่สุดของ SQLite ก็ตรงไปตรงมาที่สุด: ฐานข้อมูลคือไฟล์ที่เดินทางพร้อมแอปของคุณ ไม่มีเซิร์ฟเวอร์แยกให้ provision ไม่มีพอร์ตให้เปิด ไม่มีบัญชีผู้ใช้ให้สร้าง และไม่มีเช็คลิสต์ “ฐานข้อมูลรันอยู่ไหม?” ก่อนทุกอย่างจะทำงานได้
กับฐานข้อมูล client-server การส่งแอปมักหมายถึงต้องส่งโครงสร้างพื้นฐาน: อินสแตนซ์ DB, migrations, มอนิเตอร์, ข้อมูลการเข้าถึง และแผนการขยาย ในขณะที่กับ SQLite คุณมักจะบรรจุไฟล์ .db เริ่มต้น (หรือสร้างเมื่อรันครั้งแรก) และแอปของคุณอ่าน/เขียนโดยตรง
การอัปเดตก็ง่ายขึ้นด้วย ต้องการตารางหรือดัชนีใหม่? ส่งอัปเดตแอปที่รัน migrations กับไฟล์ท้องถิ่น สำหรับหลายผลิตภัณฑ์ นี่แปลงการปล่อยหลายขั้นตอนเป็นรีลีสเดียวได้
โมเดล “ส่งไฟล์” นี้เด่นเมื่อสภาพแวดล้อมจำกัดหรือกระจาย:
การคัดลอกไฟล์ฐานข้อมูลฟังดูง่าย และมันอาจเป็นเช่นนั้น—ถ้าทำถูกวิธี คุณไม่สามารถคัดลอกไฟล์ฐานข้อมูลที่กำลังเขียนด้วยการคัดลอกไฟล์อย่างง่ายได้ ให้ใช้กลไกแบ็กอัพของ SQLite (หรือมั่นใจใน snapshot ที่สอดคล้องกัน) และเก็บแบ็กอัพไว้ในที่ที่ทนทาน
เพราะไม่มีเซิร์ฟเวอร์ให้ปรับจูนและดูแล ทีมจำนวนมากก็หลีกเลี่ยงภาระงานบางส่วน: แพตช์บริการ DB จัดการ connection pool หมุนรหัสผ่าน และดูแล replica ให้พร้อม คุณยังต้องออกแบบสคีมาและ migrations ที่ดี แต่รอยเท้าการปฏิบัติการของฐานข้อมูลจะเล็กกว่า
ความนิยมของ SQLite ไม่ได้มาจากความสะดวกเพียงอย่างเดียว เหตุผลใหญ่ที่ผู้คนเชื่อใจมันคือมันให้ความถูกต้องของข้อมูลมาก่อนฟีเจอร์หรูหรา สำหรับหลายแอปฟีเจอร์ฐานข้อมูลที่สำคัญที่สุดคืออย่างง่าย: อย่าทำให้ข้อมูลสูญหายหรือเสียหาย
SQLite รองรับ ธุรกรรมแบบ ACID ซึ่งสรุปสั้นๆ ว่า “ข้อมูลของคุณจะคงสภาพแม้เมื่อเกิดปัญหา”
SQLite ทำให้ปลอดภัยจากการชนโดยใช้ journal—เน็ตนิรภัยที่บันทึกสิ่งที่กำลังจะเปลี่ยนแปลงเพื่อให้สามารถกู้คืนได้อย่างสะอาด
สองโหมดที่คุ้นเคย:
คุณไม่จำเป็นต้องรู้รายละเอียดภายในเพื่อได้ประโยชน์: ประเด็นคือ SQLite ถูกออกแบบมาให้กู้คืนได้อย่างคาดหมายได้
หลายแอปไม่ต้องการการจัดกลุ่มแบบพิเศษหรือชนิดข้อมูลที่แปลกประหลาด พวกเขาต้องการบันทึกที่ถูกต้อง การอัปเดตที่ปลอดภัย และความมั่นใจว่าการชนจะไม่ทำให้ข้อมูลผู้ใช้เสียหาย โฟกัสของ SQLite ที่เรื่องความถูกต้องเป็นเหตุผลสำคัญที่มันถูกใช้ในผลิตภัณฑ์ที่ “น่าเบื่อแต่ถูกต้อง” ดีกว่า “น่าประทับใจแต่ซับซ้อน”
SQLite มักให้ความรู้สึกว่า “ทันที” เพราะแอปของคุณคุยกับฐานข้อมูลในโปรเซสเดียวกัน ไม่มีเซิร์ฟเวอร์ฐานข้อมูลแยกให้เชื่อมต่อ ไม่มีการจับมือ TCP ไม่มีความหน่วงของเครือข่าย และไม่มีการรอเครื่องระยะไกล คำสั่ง SQL เป็นเพียงการเรียกฟังก์ชันที่อ่านจากไฟล์ท้องถิ่น (มักได้ประโยชน์จาก OS page cache) ดังนั้นเวลาระหว่าง “รัน SQL” ถึง “ได้แถวกลับมา” จึงสั้นอย่างน่าประหลาด
สำหรับงานหลายรูปแบบที่เป็นการอ่านเป็นส่วนใหญ่และมีการเขียนในอัตราปกติ: โหลดสถานะแอป ค้นหา กรอง การเรียง และการ join ตารางขนาดเล็กถึงปานกลาง SQLite ทำได้ดี มันสามารถทำการค้นหาด้วยดัชนี สแกนช่วงได้อย่างมีประสิทธิภาพ และสรุปเร็วเมื่อข้อมูลพอดีกับสตอเรจท้องถิ่น
งานเขียนปานกลางก็เข้ากันได้ดี—คิดถึงการตั้งค่าผู้ใช้ คิวซิงค์แบ็กกราวด์ แคชการตอบ API บันทึกเหตุการณ์ หรือตัวเก็บข้อมูล local-first ที่รวมการเปลี่ยนแปลงทีหลัง
ข้อแลกเปลี่ยนของ SQLite คือการเขียนพร้อมกัน มันรองรับผู้อ่านหลายราย แต่การเขียนต้องมีการประสานเพื่อให้ฐานข้อมูลคงสภาพ ภายใต้การเขียนพร้อมกันหนัก (หลายเธร็ด/โปรเซสพยายามอัปเดตพร้อมกัน) คุณอาจเจอการแย่งล็อกและต้อง retry หรือเจอข้อผิดพลาด “database is busy” เว้นแต่จะปรับแต่งพฤติกรรมและออกแบบรูปแบบการเข้าถึงให้เหมาะสม
SQLite ไม่ได้ “เร็วโดยอัตโนมัติ” หากคำสั่ง SQL รูปแบบไม่ดี ดัชนี เงื่อนไข WHERE ที่เฉพาะเจาะจง หลีกเลี่ยงการสแกนทั้งตาราง และการกำหนดขอบเขตธุรกรรมอย่างเหมาะสมช่วยได้มาก ถือมันเป็นฐานข้อมูลจริง—เพราะมันคือฐานข้อมูลตัวหนึ่ง
ลักษณะเด่นที่สุดของ SQLite ก็เรียบง่ายที่สุด: ฐานข้อมูลทั้งหมดของคุณเป็นไฟล์เดียว (บวกไฟล์ sidecar อย่าง WAL) ไฟล์นั้นมีสคีมา ข้อมูล ดัชนี—ทุกอย่างที่แอปต้องการ
เพราะมัน “แค่ไฟล์” การพกพาจึงกลายเป็นคุณสมบัติเริ่มต้น คุณสามารถคัดลอก มอบให้เพื่อรายงานบั๊ก แชร์กับเพื่อนร่วมงาน (เมื่อเหมาะสม) หรือย้ายระหว่างเครื่องโดยไม่ต้องตั้งค่าเซิร์ฟเวอร์ ผู้ใช้ หรือการเข้าถึงเครือข่าย
SQLite รันบนแพลตฟอร์มหลักแทบทุกตัว: Windows, macOS, Linux, iOS, Android และสภาพแวดล้อมฝังตัวมากมาย การรองรับข้ามแพลตฟอร์มนี้จับคู่กับความเสถียรระยะยาว: SQLite ระมัดระวังในความเข้ากันย้อนหลัง ดังนั้นไฟล์ฐานข้อมูลที่สร้างเมื่อหลายปีก่อนมักเปิดอ่านได้ด้วยเวอร์ชันใหม่กว่า
โมเดลไฟล์เดียวเป็นพลังสำหรับการทดสอบ ต้องการชุดข้อมูลที่ทราบค่าดีสำหรับชุดทดสอบหน่วยไหม? เช็คอินไฟล์ SQLite ขนาดเล็ก (หรือสร้างระหว่างการทดสอบ) และนักพัฒนาทุกคนรวมถึง CI จะเริ่มจากฐานเดียวกัน ต้องการทำซ้ำปัญหาลูกค้าไหม? ขอไฟล์ DB (ด้วยการจัดการความเป็นส่วนตัวอย่างเหมาะสม) แล้วคุณสามารถรันซ้ำปัญหาได้ท้องถิ่น—ไม่ต้องมีคำว่า “มันเกิดขึ้นเฉพาะบนเซิร์ฟเวอร์ของพวกเขา”
ความพกพานี้สองด้าน: หากไฟล์ถูกลบหรือเสียหาย ข้อมูลก็หาย ถือไฟล์ SQLite เหมือนทรัพย์สินสำคัญของแอป:
SQLite เรียนรู้ได้ง่ายบางส่วนเพราะคุณไม่ค่อยเริ่มจากศูนย์ มันฝังอยู่ในแพลตฟอร์มหลายตัว มาพร้อมกับ runtime ของภาษา และมีความเข้ากันได้ที่ “น่าเบื่อแต่ตรงไปตรงมา” ซึ่งคุณต้องการสำหรับฐานข้อมูลที่ฝังในแอป
สแตกส่วนใหญ่มีเส้นทางไปสู่ SQLite ที่ใช้ได้จริง:
sqlite3 ในไลบรารีมาตรฐาน), Go (mattn/go-sqlite3), Java (JDBC drivers), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).ความกว้างของการรองรับนี้สำคัญเพราะหมายความว่าทีมของคุณสามารถใช้แบบแผนคุ้นเคย—migrations ตัวสร้างคำสั่ง query การจัดการการเชื่อมต่อ—โดยไม่ต้องประดิษฐ์ท่อเชื่อมเอง
เครื่องมือของ SQLite เข้าถึงง่ายผิดปกติ sqlite3 CLI ทำให้ตรวจสอบตาราง รันคำสั่ง SQL ดัมพ์ข้อมูล หรือนำเข้า CSV ได้ง่าย สำหรับการสำรวจแบบภาพ มีตัวดูฐานข้อมูลทั้งบนเบราว์เซอร์และเดสก์ท็อป (เช่น SQLiteStudio หรือ DB Browser for SQLite) ที่ช่วยให้คนที่ไม่ใช่ผู้เชี่ยวชาญตรวจสอบข้อมูลได้เร็ว
ด้านการส่งมอบ เครื่องมือ migration หลักมักรองรับ SQLite โดยตรง: Rails migrations, Django migrations, Flyway/Liquibase, Alembic, และ Prisma Migrate ทำให้การเปลี่ยนสคีมาเกิดซ้ำได้
เพราะ SQLite ถูกใช้งานอย่างกว้างขวาง ปัญหามักได้รับการเข้าใจดี ไลบรารีถูกทดสอบในสนาม ขอบเขตปัญหาถูกจดเอกสาร และตัวอย่างจากชุมชนมีมาก ความนิยมนี้ให้การสนับสนุนมากขึ้น ซึ่งทำให้การนำไปใช้ยิ่งง่ายขึ้น
เมื่อเลือกไลบรารี ให้เลือกไดรเวอร์/adapter ORM ที่ยังได้รับการดูแลและตรวจสอบพฤติกรรมการทำงานพร้อมกัน การรองรับ binding และวิธีการจัดการ migrations การรวมที่สนับสนุนดีมักเป็นความแตกต่างระหว่างการเปิดตัวที่ราบรื่นกับสุดสัปดาห์แห่งเซอร์ไพรส์
SQLite เข้าใจง่ายสุดเมื่อดูว่ามันถูกใช้อย่างไรในโลกจริง: ที่ที่เซิร์ฟเวอร์เต็มรูปแบบจะเพิ่มค่าใช้จ่าย ความซับซ้อน และจุดล้มเหลว
แอปมือถือหลายตัวต้องการสโตร์ท้องถิ่นที่เชื่อถือได้สำหรับเซสชันผู้ใช้ เนื้อหาที่แคช โน้ต หรือคิวที่ต้องอัปโหลดทีหลัง SQLite เหมาะเพราะเป็นไฟล์เดียวที่มีธุรกรรม ACID ทำให้ข้อมูลรอดพ้นจากการชน แบตหมดกะทันหัน และการเชื่อมต่อไม่เสถียร
นี่เด่นชัดในแอป offline-first และ local-first: เขียนทุกการเปลี่ยนแปลงในเครื่อง แล้วซิงค์เมื่อเครือข่ายพร้อม ประโยชน์ไม่ใช่แค่ออฟไลน์ แต่คือ UI ที่เร็วและพฤติกรรมที่คาดเดาได้เพราะการอ่าน/เขียนยังคงอยู่บนอุปกรณ์
ซอฟต์แวร์เดสก์ท็อปมักต้องการฐานข้อมูลโดยไม่ขอให้ผู้ใช้ตั้งค่าอะไร การส่งไฟล์ SQLite เดียว (หรือสร้างเมื่อรันครั้งแรก) ทำให้การติดตั้งเรียบง่ายและการสำรองเข้าใจได้: คัดลอกไฟล์เดียว
แอปอย่างเครื่องมือบัญชี ผู้จัดการมีเดีย และระบบ CRM เบา ๆ ใช้ SQLite เพื่อเก็บข้อมูลใกล้แอป ซึ่งช่วยเพิ่มประสิทธิภาพและหลีกเลี่ยงปัญหา “เซิร์ฟเวอร์ฐานข้อมูลรันอยู่ไหม?”
SQLite ปรากฏในเครื่องมือของนักพัฒนาและแอปที่ต้องการพื้นที่เก็บข้อมูลเชิงโครงสร้างสำหรับประวัติ ดัชนี และเมตาดาต้า มันเป็นที่นิยมเพราะเสถียร พกพาได้ และไม่ต้องการโปรเซสแยก
เราเตอร์ คีออสก์ จุดขาย และเกตเวย์ IoT มักเก็บการตั้งค่า บันทึก และชุดข้อมูลเล็ก ๆ ไว้ท้องถิ่น ขนาดเล็กและความสามารถในการพกพาของ SQLite ทำให้เหมาะแก่การ deploy และอัปเดต
นักพัฒนาใช้ SQLite สำหรับโปรโตไทป์รวดเร็ว ฐานข้อมูลท้องถิ่นสำหรับ dev และฟิกซ์เจอร์ทดสอบ มันไม่ต้องตั้งค่า ง่ายจะรีเซ็ต และมีความตาม determinist—ข้อดีที่แปลเป็นการทำซ้ำที่เร็วขึ้นและการรัน CI ที่เชื่อถือได้
นี่เป็นพฤติกรรมที่พบบ่อยเมื่อสร้างกับ Koder.ai: ทีมเริ่มด้วย SQLite เพื่อการทำซ้ำท้องถิ่นอย่างรวดเร็ว (หรือ deployment แบบ single-tenant) แล้วส่งออกซอร์สโค้ดที่สร้างขึ้นและย้ายไป PostgreSQL เมื่อผลิตภัณฑ์ต้องการการเขียนพร้อมกันแบบแชร์ ผู้เดียว งานนี้ช่วยให้ส่งมอบเร็วโดยไม่ติดกับทางตัน
SQLite เป็นเอนจิ้นฐานข้อมูลแบบฝัง: มันรัน ภายในกระบวนการแอปของคุณ ในรูปแบบไลบรารี แอปของคุณอ่านและเขียนไฟล์ฐานข้อมูล ไฟล์เดียว (เช่น app.db) โดยตรงบนดิสก์—ไม่ต้องติดตั้งหรือจัดการบริการฐานข้อมูลแยกต่างหาก
“Serverless” สำหรับ SQLite หมายความว่า ไม่มีโปรเซสเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก ไม่ได้หมายความว่า “รันในคลาวด์โดยไม่มีเซิร์ฟเวอร์” แอปของคุณเรียกใช้ API ของ SQLite ภายในโปรเซสเดียวกัน และ SQLite จะจัดเก็บข้อมูลในไฟล์ท้องถิ่น
โดยทั่วไปคุณไม่ต้อง provisioning อะไร: ส่งแอปพร้อมไฟล์ .db เริ่มต้น (หรือสร้างไฟล์เมื่อรันครั้งแรก) แล้วรัน migrations เป็นส่วนหนึ่งของอัปเดตแอป วิธีนี้มักจะเปลี่ยนการปรับใช้ที่มีหลายขั้นตอนให้เหลือเป็นหนึ่งอาร์ติแฟกต์การปล่อย
ใช่ SQLite รองรับ ธุรกรรมแบบ ACID ซึ่งช่วยป้องกันการเขียนไม่สมบูรณ์และการเสียหายของข้อมูลเมื่อเกิดการล้มเหลวหรือไฟดับ
SQLite มักใช้กลไก journal เพื่อกู้คืนปลอดภัยหลังการขัดจังหวะ
หลายแอปผลิตจริงเลือก WAL เพราะช่วยลดปัญหา “ฐานข้อมูลถูกล็อก” ในการใช้งาน
เพราะมันรัน ในโปรเซสเดียวกับแอป: การเรียกใช้คำสั่ง SQL เป็นการเรียกฟังก์ชัน ไม่ใช่การส่งคำขอผ่านเครือข่าย เมื่อเพิ่มดิสก์ท้องถิ่น + OS page cache งานอ่านหนักหลายรูปแบบ (ค้นหา กรอง การใช้ดัชนี) จึงตอบสนองได้เร็วโดยเฉพาะสำหรับเดสก์ท็อป มือถือ และแอป local-first
SQLite รองรับ ผู้อ่านหลายรายพร้อมกัน แต่การเขียนต้องประสานกันเพื่อให้ไฟล์คงสภาพ เมื่อมีการเขียนพร้อมกันจำนวนมากคุณอาจเจอการแย่งล็อกและข้อผิดพลาด database is busy / database is locked เว้นแต่จะออกแบบให้เขียนแบบเรียงลำดับและใช้ธุรกรรมสั้นๆ
SQLite เหมาะเมื่อหลายเครื่อง/บริการจำเป็นต้อง เขียนไปที่ฐานข้อมูลร่วมเดียวกัน หรือต้องการการควบคุมศูนย์กลาง
ควรเลือกฐานข้อมูลแบบ client-server (เช่น PostgreSQL/MySQL) เมื่อคุณต้องการ:
จัดการฐานข้อมูลเหมือนเป็นข้อมูลแอปสำคัญ:
เริ่มด้วย SQLite เมื่อแอปของคุณเป็นท้องถิ่น ผู้ใช้คนเดียว หรือมีการเขียนน้อย แล้วรักษาทางออกสำหรับการย้าย:
คำแนะนำเชิงปฏิบัติ:
/blog/migrating-from-sqlite)