• SQLite는 로컬 저장소와 임베디드 프로젝트에 널리 쓰이는 자체 완결형 RDBMS지만,
  하위 호환성때문에 안전성과 성능에 불리한 기본값을 유지하고 있음 - 기본적으로
  외래 키 제약을 강제하지 않고ROWID

를 재사용할 수 있어, 삭제된 사용자의 게시물이 같은 ID를 받은 다른 사용자에게 연결되는 데이터 무결성 문제가 생길 수 있음 - 일반 테이블은 선언된 열과 다른 자료형도 저장하며,
STRICT 테이블은 이를 막지만 테이블마다strict

를 지정해야 하고 사용자 정의 타입 이름을 활용하던 방식과 충돌함 - 동시 쓰기에서 즉시 발생하는
SQLITE_BUSY

, 비활성화된WAL, 보수적인 동기화 설정은 각각busy_timeout

,journal_mode

,synchronous

프라그마로 개선할 수 있음 PRAGMA edition = 2026

같은연도 기반 에디션으로 안전한 기본값 묶음을 선택하게 하면, 기존 동작을 깨지 않고 SQLite의 기본 설정을 계속 발전시킬 수 있음

SQLite의 강점과 낡은 기본값

• SQLite는 임베디드 프로젝트의 데이터베이스이자 로컬 데이터 저장의 업계 표준으로 부를 만하며, 일부 서버 소프트웨어인 lobste.rs도 SQLite에서 실행되고 있음
• 별도 프로세스로 실행되는 전통적인 RDBMS와 달리
  라이브러리 형태의 RDBMS여서 소프트웨어를 자체 완결형으로 유지할 수 있음 - 일반 파일 형식처럼 사용자 정의 직렬화기와 파서를 작성할 필요가 없어, RDBMS와 파일 기반 저장 방식의 장점을 함께 제공함
• 그러나 데이터 무결성, 동시성, 성능에 영향을 주는 여러
  기본값이 부적절하다는 문제가 남아 있음

외래 키를 강제하지 않아 생기는 무결성 문제

• 외래 키는 데이터베이스의 일관성을 유지하고
  끊어진 참조를 방지하는 핵심 수단이지만, SQLite는 기본적으로 이를 강제하지 않음 posts.user_id

가users.id

를 참조하도록 선언해도 기본 설정에서는 다음 동작을 막지 못함- 유효한 사용자 ID가 없는 게시물 생성

• 해당 사용자의 게시물을 남겨둔 채 사용자 삭제

INTEGER PRIMARY KEY

는 테이블의ROWID

별칭이 되며, SQLite의ROWID

할당 알고리듬은 일부 상황에서 ID를 재사용함- Bob이 ID
1

로 게시물을 작성한 뒤 계정만 삭제해도 외래 키 오류가 발생하지 않음 - 이후 Alice가 재사용된 ID
1

을 받으면 Bob의 기존 게시물이 Alice에게 연결됨 - 조회 자체는 정상적으로 성공하므로 단순한 끊어진 참조보다 문제를 발견하기 어려움

• Bob이 ID
• 연결마다 다음 프라그마를 활성화하면 외래 키를 강제할 수 있음

PRAGMA foreign_keys = ON;

• 이를 처음부터 적용했다면 게시물을 남긴 사용자 삭제는
  FOREIGN KEY constraint failed

오류로 중단됨

선언과 다른 자료형을 허용하는 일반 테이블

• SQLite 값은
  NULL

,INTEGER

,REAL

,TEXT

,BLOB

가운데 하나지만, 일반 테이블의 열 선언은 저장 가능한 자료형을 엄격히 제한하지 않고**타입 친화도(type affinity)**를 결정함 INTEGER

친화도 열에는 다음 저장 규칙이 적용됨- 정수로 해석할 수 있는
TEXT

는INTEGER

로 변환함 - 실수로 해석할 수 있는
TEXT

는 배정밀도 부동소수점인REAL

로 변환함 - 그 밖의 값은 원래 자료형 그대로 저장함

• 정수로 해석할 수 있는
• 다른 친화도에도 별도 변환 규칙이 있음
  BLOB

친화도는 값을 그대로 저장함TEXT

친화도는BLOB

,TEXT

,NULL

을 그대로 두고 숫자를TEXT

로 변환함REAL

친화도는INTEGER

친화도처럼 동작하지만 정수를REAL

로 변환함

• 이 때문에
  duration_sec INTEGER

열에도 숫자가 아닌'Way too long, I mean come on'

같은 문자열을 저장할 수 있음 - 실제 프로젝트에서는 불리언용 숫자
1

,0

대신 문자열'1'

,'0'

이 기록되어 데이터를 정리하고 디버깅해야 했던 사례도 있었음

STRICT 테이블과 사용자 정의 타입의 충돌

• STRICT 테이블은 열에 잘못된 자료형을 넣으면
  cannot store TEXT value in INTEGER column

같은타입 오류를 발생시킴

CREATE TABLE music (
id INTEGER PRIMARY KEY,
name TEXT,
duration_sec INTEGER
) strict;

모든 테이블을 전역적으로 엄격하게 만드는 프라그마는 없으므로, 각

CREATE TABLE

문에strict

를 빠짐없이 추가해야 함 -
SQLite는 유연한 타입이 유용하다는 입장이지만, STRICT 테이블에서도

ANY

자료형을 명시하면 모든 종류의 값을 저장하는 열을 만들 수 있음- 임의 자료형을 허용할 열과 특정 자료형을 강제할 열을 명시적으로 구분할 수 있음

더 현실적인 호환성 문제는 STRICT 테이블이 자료형을 강제하는 데 그치지 않고

타입 지정자 해석 규칙까지 바꾼다는 점임 -

일반 테이블이 타입 이름을 해석하는 방식

• 일반 SQLite 테이블은 선언된 타입 문자열에 따라 친화도를 정함
  "INT"

가 포함되면INTEGER

로 처리함"CHAR"

,"CLOB"

,"TEXT"

중 하나가 포함되면TEXT

가 됨"BLOB"

이 포함되거나 타입을 생략하면BLOB

으로 처리함"REAL"

,"FLOA"

,"DOUB"

중 하나가 포함되면REAL

이 됨- 어느 조건에도 해당하지 않으면
NUMERIC

으로 처리함 - 느슨한 타입과 이 규칙을 결합하면
DATETIME

,KEY_VALUE_SET

,COLOR

같은사용자 정의 타입 이름을 열에 붙일 수 있음 - 데이터베이스 커넥터나 래퍼는 타입 이름을 보고 자동으로 직렬화·역직렬화할 수 있음

• 별도 처리 기능이 없더라도 타입 이름 자체가 열의 예상 데이터를 문서화함
• STRICT를 그대로 기본값으로 바꾸면 이 활용법을 포기해야 하므로, 명시적인 사용자 정의 타입 별칭이 필요함

CREATE TYPE KEY_VALUE_SET = TEXT;

• 엄격한 테이블에서
  KEY_VALUE_SET

같은 별칭을 사용할 수 있다면, 애플리케이션에서 파싱해야 하는TEXT

열의 예상 데이터 패턴도 스키마에 기록할 수 있음 - 사용자 정의 타입에
CHECK

제약을 연결하는 기능도 유용함 - SQL:1999 표준에는 제약까지 지원하는 타입 별칭 문법인
이 이미 있으므로, SQLite가 이 표준 문장을 지원하는 방식으로 구현할 수 있음CREATE DOMAIN

동시 쓰기와 SQLITE_BUSY

• SQLite는 여러 동시 읽기를 허용하지만, 쓰기는 한 번에 하나만 처리함
• 기본 설정에서는 두 프로세스가 동시에 쓰기 잠금을 얻으려 할 때 하나가 기다리지 않고 즉시
  를 받음SQLITE_BUSY

오류- 디스크 I/O를 수행하는 쓰기는 원래 느려질 수 있으므로, 일정 시간 잠금 해제를 기다리는 편이 더 자연스러움

• 실제 시스템이 간헐적으로 중단되어 직접 재시도 루프를 작성해야 했던 사례도 있음

• 다음 설정은 최대 5초 동안 잠금 획득을 재시도한 뒤에만
  SQLITE_BUSY

를 반환함

PRAGMA busy_timeout = 5000;

• 정상 운영에서는 모든 쓰기를 단일 프로세스, 가능하면
  단일 스레드에 모으는 편이 적절하며 동시 쓰기가 빠를 수는 없음 - 다만 동시 쓰기가 필요한 정상적인 운영 사례도 있음
  sqlite3

명령줄 도구로 데이터베이스를 대화형으로 정리- 별도 프런트엔드가 없는 드문 관리 작업용 스크립트 실행

• 이런 작업은 기본 설정 때문에 예상하지 못한
  SQLITE_BUSY

를 일으켜 실행 중인 소프트웨어를 중단시킬 수 있음

WAL과 성능 기본값

• SQLite는 올바르게 설정하면 PostgreSQL이나 MySQL 같은 대형 서버가 맡던 역할도 일부 수행할 만큼 빠를 수 있지만, 기본 성능은 좋지 않음
• 서버 환경의 세부 튜닝은 Optimizing SQLite for servers에서 더 확인할 수 있음
• 가장 중요한 기본값 문제는 Write-Ahead Log, 즉
  WAL이 비활성화되어 있다는 점임

PRAGMA journal_mode = WAL;

• WAL은 대부분의 상황에서 쓰기 속도를 크게 높임
• 다음 설정을 함께 사용하면 데이터 손상 위험 없이 디스크 동기화 횟수를 크게 줄일 수 있음

PRAGMA synchronous = NORMAL;

synchronous

의 구체적인 동작은 SQLite 프라그마 문서에 정리되어 있음

연도 기반 SQLite 에디션

• 기존 기본값을 지금 직접 변경하면 오래된 소프트웨어가 깨지고, 사용자가 향후 SQLite 업그레이드를 두려워하게 될 수 있음
• 하위 호환성을 유지하면서 개선된 기본값을 선택하도록 하나의
  **상위 프라그마(super pragma)**를 추가할 수 있음

PRAGMA edition = 2026;

2026

에디션은 최소한 다음 설정의 별칭으로 동작함

PRAGMA foreign_keys = ON;
PRAGMA busy_timeout = 5000;
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

• 이 에디션에서는 새 테이블의
  strict

모드도 기본값으로 적용함 - Rust editions처럼 기존 코드의 동작을 보존하면서 새로운 기본 동작을 명시적으로 선택하는 방식임

• JavaScript의
  "use strict";

같은 단일 모드와 달리, 연도 기반 에디션은 시대에 따라 합리적인 기본값 묶음을 바꿀 수 있음 - 예를 들어 Hctree의 WAL2가 2034년에 메인 브랜치에 들어간다면, 미래의
PRAGMA edition = 2034

가journal_mode = WAL2

를 선택하도록 구성할 수 있음 - 에디션 체계는 기존 프로그램의 기본 동작을 깨지 않으면서도 SQLite가 과거 설정에 묶이지 않고
안전성과 성능 기본값을 발전시키는 절충안이 될 수 있음