임베디드 데이터베이스의 사실상 표준으로 불리는 SQLite의 기본 설정이 데이터 무결성(Data Integrity)에 심각한 문제를 일으킬 수 있다는 주장이 제기되었습니다. 개발자 Mort는 자신의 블로그를 통해 SQLite가 다른 관계형 데이터베이스 관리 시스템(RDBMS)과 달리 외래 키(Foreign Key) 제약 조건을 기본적으로 무시하고, 컬럼(Column)에 잘못된 데이터 타입을 허용하는 점을 비판했습니다. 이는 개발자가 명시적으로 설정을 변경하지 않으면 예기치 않은 데이터 손상이나 논리적 오류로 이어질 수 있습니다.
가장 큰 문제로 지적된 것은 외래 키 제약 조건이 기본적으로 비활성화되어 있다는 점입니다. 이는 테이블 간의 참조 무결성을 보장하는 핵심 기능임에도 불구하고, SQLite는 `PRAGMA foreign_keys = ON;` 명령어를 통해 개발자가 직접 활성화해야만 작동합니다. 이로 인해 부모 레코드가 삭제되어도 자식 레코드가 남아있는 '댕글링 참조(Dangling Reference)'가 발생할 수 있으며, SQLite의 ROWID 재사용 특성과 결합될 경우, 삭제된 레코드의 ID가 재사용되면서 엉뚱한 데이터가 연결되는 심각한 오류로 이어질 수 있습니다. 또한, 컬럼에 정의된 데이터 타입과 다른 타입의 데이터를 삽입해도 오류 없이 저장되는 '유연한 타입 시스템' 역시 문제로 지적됩니다. 예를 들어, `INTEGER` 타입 컬럼에 문자열을 넣어도 SQLite는 이를 숫자로 변환하여 저장하거나, 변환이 불가능하면 그대로 저장해버립니다. 이는 데이터 유효성 검사를 어렵게 하고, 디버깅을 복잡하게 만드는 원인이 됩니다. 다행히 `STRICT` 키워드를 사용하여 엄격한 테이블을 생성하면 이러한 문제를 방지할 수 있습니다.
이러한 문제들은 SQLite가 가진 '작고 빠르며 설정이 필요 없는' 철학에서 비롯된 것으로 보입니다. 하지만 현대적인 애플리케이션 개발 환경에서는 데이터 무결성과 안정성이 더욱 중요해지고 있습니다. Mort는 러스트(Rust) 언어의 '에디션(Edition)' 시스템처럼, SQLite도 새로운 버전(에디션)을 출시할 때 안전한 기본값(예: 외래 키 활성화, 엄격한 타입 검사)을 적용하여 개발자들이 더 안전하게 데이터베이스를 사용할 수 있도록 해야 한다고 제안했습니다. 이는 기존 코드와의 호환성을 유지하면서도 점진적으로 더 나은 기본값을 도입할 수 있는 효과적인 방법이 될 수 있습니다. 이러한 변화는 SQLite를 사용하는 수많은 개발자와 애플리케이션의 안정성을 크게 향상시킬 것입니다.