SQLite, 기본 설정 개선을 위한 '에디션' 시스템 도입 논의

글쓴이는 SQLite의 외래 키 제약 조건(Foreign Key Constraints)이 기본적으로 비활성화되어 데이터 무결성을 해치고, 느슨한 데이터 타입(Loose Data Typing)으로 인해 예상치 못한 타입 오류가 발생하며, SQLITE_BUSY 오류가 동시 쓰기 시 즉시 발생하고 WAL(Write-Ahead Log)이 기본 비활성화되는 등 여러 기본 설정이 부적절하다고 지적합니다. 이를 해결하기 위해 Rust의 'edition'처럼 특정 연도를 기준으로 일련의 최적 기본 설정(Optimized Defaults)을 적용하는 '에디션' 시스템 도입을 제안합니다.

커뮤니티에서는 SQLite의 유연한 타입 시스템(Flexible Typing)이 오히려 문제를 야기한다는 점에 공감하며, 이를 해결하기 위한 방안으로 SQL 표준인 CREATE DOMAIN 구문을 제안합니다. `CREATE DOMAIN`을 사용하면 사용자 정의 타입 별칭(Type Aliases)을 생성하고 기본값 및 제약 조건을 설정할 수 있어, 명시적인 타입 정의(Explicit Type Definition)와 함께 코드 가독성(Code Readability)을 높일 수 있다는 의견입니다. 이는 SQLite가 기존의 'quirk'를 포기하지 않으면서도 타입 안전성을 강화할 수 있는 방안으로 제시됩니다.

제안된 '에디션' 시스템은 연결(Connection) 속성(예: `PRAGMA foreign_keys = ON`)과 파일(File) 속성(예: `PRAGMA journal_mode = WAL`), 그리고 테이블(Table) 속성(예: `STRICT`) 등 다양한 수준의 설정을 포함합니다. 따라서 '슈퍼 프라그마(Super Pragma)'가 데이터베이스 파일 자체의 속성인지, 아니면 각 연결마다 설정해야 하는 속성인지 명확히 정의해야 하는 구현상의 과제가 존재합니다. 또한, 이전 버전의 SQLite 라이브러리가 알지 못하는 새로운 설정을 편집할 때 발생할 수 있는 호환성 문제(Compatibility Issues)에 대한 고려도 필요합니다.

일부 논의에서는 SQLite가 관계형 데이터베이스(RDBMS)라는 점에 주목하며, RocksDB와 같은 임베디드 키-값(Key-Value, KV) 데이터베이스를 대안으로 제시합니다. KV 데이터베이스는 SQL 없이 직접 데이터에 접근하여 단순한 작업(캐싱, 작업 큐 등)에 더 효율적일 수 있다는 주장입니다. 하지만 관계형 모델(Relational Model)을 깊게 사용하는 애플리케이션의 경우, KV 데이터베이스로의 전환은 복잡한 변환 작업이 필요하며, SQLite의 SQL 인터페이스와는 근본적으로 다르다는 반론도 존재합니다.

동시 쓰기 시 발생하는 SQLITE_BUSY 오류는 기본적으로 즉시 발생하며, `PRAGMA busy_timeout` 설정만으로는 모든 경우를 방지하기 어렵다는 지적이 있습니다. 특히 읽기 전용 트랜잭션에서 쓰기 트랜잭션으로 업그레이드하려는 시점에 다른 쓰기 작업이 존재하면 `busy_timeout` 설정과 무관하게 즉시 오류가 발생할 수 있습니다. 이를 해결하기 위해 `BEGIN IMMEDIATE` 구문을 사용해야 한다는 구체적인 해결책이 제시되었으며, 이는 예상치 못한 오류로 인한 시스템 충돌을 방지하는 데 중요합니다.