SQLite: یہ کب کافی ہے
VPS پر SQLite الگ ڈیٹا بیس سرور سے کہاں بہتر ہے، WAL کیسے فعال کریں اور “database is locked” سے کیسے بچیں، اور PostgreSQL پر کب منتقل ہونا چاہیے۔
اپ ڈیٹ 23 اگست، 2026
SQLite ایک ہی فائل میں موجود ڈیٹا بیس ہے — نہ کوئی سروس، نہ پورٹ، نہ پاس ورڈ۔ بوٹ، چھوٹے پینل یا ایسی سائٹ کے لیے جو کبھی کبھار لکھتی ہو، یہی درست انتخاب ہے: یہ میموری نہیں کھاتا، اور VDS-1 میں صرف 2 GB ہی موجود ہے، نیز کنفیگر کرنے کے لیے کچھ نہیں۔
کب استعمال کریں
موزوں ہے:
- Telegram اور Discord بوٹس، کاؤنٹرز، سیٹنگز؛
- ایسی سائٹیں جن میں فی منٹ ہزاروں ریڈز اور درجنوں رائٹس ہوں؛
- ایک ہی مشین پر کوئی بھی پروجیکٹ جس میں دوسرے سرور کا کوئی ارادہ نہ ہو۔
موزوں نہیں ہے:
- متعدد پروسیسز کا بیک وقت فعال طور پر لکھنا؛
- چند درجن گیگا بائٹس سے بڑا ڈیٹا بیس؛
- کسی دوسری مشین سے نیٹ ورک رسائی — SQLite یہ بالکل نہیں کر سکتا۔
دوسری اور تیسری صورت میں PostgreSQL یا MySQL استعمال کریں۔
فائل کے ساتھ کام کرنا
apt install -y sqlite3
sqlite3 /srv/app/data/app.db
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO users (name) VALUES ('test');
.tables
.schema users
.quit
ڈیٹا بیس فائل مشین کی لوکل ڈسک پر ہونی چاہیے اور اس کی ملکیت ایپلیکیشن یوزر کے پاس ہونی چاہیے:
chown appuser:appuser /srv/app/data/app.db
chmod 640 /srv/app/data/app.db
ڈیٹا بیس والی ڈائریکٹری بھی قابلِ تحریر ہونی چاہیے: SQLite اس کے ساتھ ہی عارضی -wal اور -shm فائلیں بناتا ہے۔
لازمی سیٹنگز
دو pragma سیٹنگز زیادہ تر مسائل ختم کر دیتی ہیں:
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
WAL قارئین کو لکھائی جاری رہنے کے دوران پڑھنے دیتا ہے — اس کے بغیر کوئی بھی قاری لکھنے والے کی وجہ سے بلاک رہتا ہے۔ busy_timeout کلائنٹ کو فوری ناکام ہونے کے بجائے پانچ سیکنڈ انتظار کرواتا ہے۔ انہیں ہر بار کوڈ میں کنکشن کھولتے وقت سیٹ کریں، کنسول میں ایک بار نہیں۔
بیک اپ
ایپلیکیشن چلنے کے دوران آپ سادہ cp سے فائل کاپی نہیں کر سکتے — آپ کو خراب ڈیٹا بیس ملے گا۔ ایک بلٹ اِن محفوظ کمانڈ موجود ہے:
sqlite3 /srv/app/data/app.db ".backup '/srv/backups/app-$(date +%F).db'"
اسے cron میں ڈالیں اور کاپی مشین سے باہر منتقل کریں: VPS میں نہ خودکار بیک اپ ہے اور نہ ہی اسنیپ شاٹس۔ عمومی طریقہ ڈیٹا بیس بیک اپ میں بیان کیا گیا ہے۔
عام غلطیاں
| علامت | وجہ |
|---|---|
database is locked | WAL یا busy_timeout نہیں، یا دوسرا پروسیس طویل ٹرانزیکشن تھامے ہوئے ہے |
attempt to write a readonly database | فائل یا ڈائریکٹری پر اجازتیں نہیں |
disk I/O error | ڈسک کی جگہ ختم — ”Overview“ میں ڈسک استعمال کا رنگ دیکھیں |
| قطاریں حذف کرنے کے بعد ڈیٹا بیس بڑھتا ہے | جگہ خودکار طور پر واپس نہیں آتی: VACUUM |
| کاپی کرنے کے بعد ڈیٹا بیس خراب | آپ نے چلتے ہوئے cp سے کاپی کیا — صرف .backup استعمال کریں |
کب منتقل کریں
نشانیاں: WAL فعال ہونے کے باوجود باقاعدہ database is locked غلطیاں، متعدد ایپلیکیشن ورکرز، ایسی رپورٹس جن کا حساب لگانے میں منٹوں لگیں۔ منتقلی کے لیے ڈیٹا بیس منتقلی دیکھیں۔
ڈیٹا بیس فائل ایسی ڈائریکٹری میں نہیں ہونی چاہیے جو ویب سرور پیش کرتا ہو۔
/var/www/app.dbبراہِ راست لنک کے ذریعے ڈاؤن لوڈ ہو سکتی ہے، تمام پاس ورڈز اور یوزر ڈیٹا سمیت۔