SQLite를 사용하는 앱은 C로 작성된 외부 라이브러리를 바인딩하고 작업할 수 있는 수단이 있는 한 특정 언어로 작성하지 않아도 된다. SQLite의 바이너리는 그 자체로 완성되어 있으므로 배포를 위한 특별한 방법이 필요 없으며, 그냥 애플리케이션과 동일한 디렉토리에 넣으면 된다.

많은 언어에는 SQLite를 위한 고수준 바인딩이 라이브러리로 존재한다. 또한 이 라이브러리를 해당 언어를 위한 다른 데이터베이스 액세스 계층과 함께 사용할 수 있다. 예를 들어 파이썬은 파이썬 인터프리터 기본 버전과 함께 SQLite 라이브러리를 표준 번들 요소로 제공한다. 또한 SQLite를 사용하는 다양한 서드파티 ORM 및 데이터 계층이 있으므로 원시 SQL 문자열(불편할 뿐만 아니라 위험하기도 함)을 통해서만 SQLite에 액세스할 필요도 없다.

마지막으로, SQLite의 소스 코드는 공개돼 있으므로 실질적으로 아무런 제약 없이 다른 프로그램에서 재사용할 수 있다.

SQLite의 장점

SQLite의 가장 일반적이며 대표적인 사용사례는 전통적인 테이블 지향 관계형 데이터베이스 역할이다. SQLite는 트랜잭션과 원자성 동작을 지원하므로 프로그램 충돌이나 정전이 발생하더라도 데이터베이스가 손상되지 않는다.

SQLite에는 전체 텍스트 인덱싱, JSON 데이터 지원 등 고급 데이터베이스에서 볼 수 있는 여러 기능이 있다. 일반적으로 YAML 또는 XML과 같이 반구조적인 형식으로 저장되는 애플리케이션 데이터는 SQLite 테이블로 저장할 수 있으므로 데이터에 더 쉽게 액세스하고 더 신속하게 처리할 수 있다.

SQLite는 프로그램의 구성 데이터를 저장하는 빠르고 강력한 수단도 제공한다.

개발자는 YAML과 같은 파일 형식을 파싱하는 대신 SQLite를 이러한 파일의 인터페이스로 사용할 수 있다. 대부분의 경우 이 편이 수작업보다 훨씬 더 빠르다. SQLite는 메모리 내 데이터로 작업하거나 외부 파일(CSV 파일 등)을 네이티브 데이터베이스 테이블처럼 사용할 수 있으므로 편리한 데이터 쿼리가 가능하다.

그 외에도 많은 서드파티 프로젝트가 SQLite를 위한 부가적인 도구를 제공한다.

예를 들어 비주얼 스튜디오 코드 내에서 데이터베이스를 탐색할 수 있게 해주는 비주얼 스튜디오 코드 확장 또는, SQLite용 LiteCLI 인터랙티브 명령줄이 있다.

그 외에도 깃허브의 추천 SQLite 리소스 목록에서 많은 도구를 찾을 수 있다.

SQLite가 적합하지 않은 경우

SQLite는 설계 원칙상 잘 맞는 시나리오와 그렇지 않은 시나리오가 뚜렷이 구분된다.

SQLite가 적합하지 않은 경우는 다음과 같다.

•

SQLite가 지원하지 않는 기능을 사용하는 앱.

SQLite는 여러 가지 관계형 데이터베이스 기능을 지원하지 않으며 많은 경우 앞으로도 지원할 예정이 없다. 대체로 코너 케이스에 해당하는 기능이지만, 그 기능이 필요하다면 사용할 수 없다.

•

수평 확장 설계가 필요한 앱.

SQLite 인스턴스는 단일체이며 독립적이고, 인스턴스 간 기본 동기화 기능이 없다. 또한 여러 개를 연합하거나 클러스터를 만들 수 없다.

따라서 수평 확장 설계를 사용하는 애플리케이션에서는 SQLite를 사용할 수 없다.

•

여러 연결에서의 동시 쓰기 작업을 실행하는 앱.

SQLite는 쓰기 작업 시 데이터베이스를 잠그므로 여러 동시 쓰기 작업이 실행되는 앱에서는 성능 문제가 발생할 수 있다.

다만 여러 동시 읽기 작업을 실행하는 앱은 대체로 빠르게 실행된다. SQLite 3.7.0 이상은 여러 쓰기 작업의 속도를 높이기 위한 로그 선행 기입(Write-Ahead Logging)을 제공하지만 몇 가지 제약이 따른다. 대안으로는 위에 언급한 버클리 DB가 있다.

•

강한 데이터 형식 지정이 필요한 앱.

SQLite의 데이터 형식은 비교적 소수다.

예를 들어 기본 datetime 형식이 없다.

따라서 애플리케이션에서 이러한 형식을 처리해야 한다.

애플리케이션이 아닌 데이터베이스에서 datetime 값을 위한 입력을 정규화하고 제약하고자 한다면 SQLite는 적합하지 않다.