웹 브라우저에서 SQLite 데이터를 영속화하는 방법과 VFS 구현 옵션, 동시성·비동기 처리·성능·호환성 고려사항을 정리하고, wa-sqlite와 sqlite-wasm 등의 구현을 비교한 업데이트.
이 글은 웹 브라우저에서 SQLite 영속성(퍼시스턴스) 환경을 종합적으로 정리한 글입니다. 원문 최초 게시 이후 변경된 내용은 글 끝의 변경 로그를 참고해 주세요. 또한 내용에 오류가 있다고 판단되면 문의하기로 알려 주세요.
이 글의 요약은 Sync Conf 2025에서 발표로도 다뤄졌습니다. 영상은 여기에서 볼 수 있습니다.
SQLite는 전 세계에서 가장 널리 배포된 데이터베이스입니다. 최근에는 브라우저 기반 애플리케이션에서 데이터 영속성 옵션으로도 주목받고 있습니다.
웹 브라우저로 SQLite를 가져오는 프로젝트는 몇 가지가 있습니다:
참고: 과거에는 Chrome과 오래된 Safari 버전에 내장되어 있던 Web SQL 프로젝트도 있었습니다(하지만 Firefox에는 들어간 적이 없습니다). 브라우저 간 표준이 되기에는 제한과 난점이 너무 많았고 현재는 폐기(deprecated)되었습니다. 그 이유로, 이 글에서는 더 이상 다루지 않습니다.
현재 이들 프로젝트 중 어느 것도 영속성에 대해 “프로덕션 수준의 안정성”을 주장하지는 않지만, 현 시점의 지원만으로도 특정 용도에서는 충분하다는 것을 확인했습니다. 다만 선택지가 많고, 각각의 장단점이 바로 명확하지 않을 수 있습니다.
이 글은 웹 브라우저에서 SQLite 데이터를 영속화할 때 고려해야 하는 다양한 요소를, 현재 구현들이 실제로 어떻게 동작하는지와 함께 개관합니다. 지금 당장 무엇을 써야 하는지만 알고 싶다면 글 끝의 권장 사항으로 건너뛰어도 됩니다.
SQLite는 하나의 데이터베이스 파일에 대한 동시 접근을, 파일에 대한 여러 “연결(connection)”을 통해 지원합니다. 동시성은 스레드 안전성과 혼동하면 안 됩니다: 하나의 연결은(사용한 컴파일 옵션에 따라) 서로 다른 네이티브 스레드에서 “안전하게” 사용할 수 있을지라도, 문장을 직렬화하며 한 번에 하나의 트랜잭션만 실행할 수 있습니다.
여러 트랜잭션을 동시에 실행하려면 여러 연결을 사용할 수 있습니다. 각 연결은 독립적으로 동작하고 파일 시스템을 통한 잠금(locking)을 사용하므로, 같은 머신에서 서로 다른 스레드에서 연결을 쓰든 서로 다른 프로세스에서 연결을 쓰든 효과는 동일합니다.
기본적으로 SQLite는 손상 방지를 위해 롤백 저널(DELETE, TRUNCATE 또는 PERSIST 모드)을 사용하며, 트랜잭션 롤백을 지원합니다. 한 번에 하나의 트랜잭션만 롤백 저널을 수정할 수 있으므로, 한 번에 하나의 쓰기 트랜잭션만 실행될 수 있습니다. 동시에 쓰기를 시도하는 다른 트랜잭션은 SQLITE_BUSY로 실패합니다. 또한 쓰기 트랜잭션이 활성화되어 있는 동안에는 읽기 트랜잭션도 수행할 수 없습니다. 자세한 내용은 공식 문서에 있습니다.
대신 WAL 저널 모드를 사용하면 동시성 제약이 다소 완화됩니다: 단일 쓰기 트랜잭션과 동시에 읽기 트랜잭션을 실행할 수 있습니다. 또한 동일한 페이지를 사용하지 않는 한 여러 동시 쓰기 트랜잭션을 허용하는 실험적 WAL2 모드도 있습니다. 이는 아직 실험 단계이며 별도의 SQLite 브랜치에 있으므로 여기서는 다루지 않습니다.
SQLite에는 어떤 시스템에서든 파일 시스템을 구현할 수 있게 하는 VFS 인터페이스가 있습니다. 일반적으로 구현은 데이터 블록 쓰기, 데이터 블록 읽기, 파일 시스템으로의 플러시, 파일 잠금 같은 메서드를(그리고 더 고급 메서드들도) 제공해야 합니다.
웹 브라우저에서 기반 저장소로 사용할 수 있는 대표적인 선택지는 두 가지입니다:
localStorage 같은 다른 옵션은 제약이 너무 크므로 여기서는 다루지 않습니다.
C 기반 라이브러리인 SQLite는 동기(synchronous) 연산을 사용합니다. Wasm으로 컴파일하더라도 이는 동일하므로, JavaScript로 작성된 VFS 구현 역시 동기여야 합니다. 이는 파일 시스템 연산이 보통 비동기인 JavaScript 세계에서는 문제가 됩니다.
이를 처리하기 위한 여러 우회 방법이 존재합니다:
Asyncify는 동기 호출을 비동기 호출로 변환해 VFS 구현을 비동기로 만들 수 있게 합니다. 단점은 다음과 같습니다:
기본 아이디어는 여기에 설명되어 있습니다. 이 접근은 파일 시스템 연산을 위한 별도 Worker 프로세스 실행이 필요합니다. 또한 SharedArrayBuffer를 안전하게 사용하기 위해 웹 오리진에 추가 제약이 걸립니다. 필요한 COOP 및 COEP 헤더는 여기에 설명되어 있습니다.
또한 이 메커니즘을 사용하는 지점마다 상당한 오버헤드가 추가됩니다.
새로운 WebAssembly JavaScript Promise Integration (JSPI)은 Asyncify와 유사한 기능을 브라우저 핵심 기능으로 제공합니다. JSPI는 Chrome 137(2025년 5월)부터 기능 플래그 없이 사용 가능하며, Firefox에서는 131(2024년 10월)부터 기능 플래그를 켠 상태에서 사용할 수 있습니다. Safari는 아직 지원하지 않지만, Safari가 향후 JSPI를 지원할 수 있다는 정황이 있습니다.
File System API는 전용 Worker(dedicated Worker) 안에서 createSyncAccessHandle()로 FileSystemSyncAccessHandle을 획득할 수 있게 하며, 이는 OPFS 내 파일에 대해 동기 읽기/쓰기 접근을 제공합니다. 최신 Chrome, Safari, Firefox는 모두 이를 지원합니다.
주의할 점이 있습니다:
2023년 WHATWG 제안에 기반해 createSyncAccessHandle()에 mode 인자가 도입되고 있으며, readwrite-unsafe 모드는 다수의 동시 읽기/쓰기를 허용합니다. readwrite-unsafe 모드는 Chrome 121+에서 사용할 수 있지만, Firefox나 Safari는 아직 지원하지 않습니다.
OPFS createSyncAccessHandle()을 쓰더라도, 파일 접근 핸들을 얻는 과정은 비동기입니다. 우회 방법 중 하나는 Wasm 바깥의 JavaScript 레이어에서 파일 핸들이나 잠금을 열어 두는 것입니다. wa-sqlite 프로젝트의 OPFSCoopSyncVFS가 그 예입니다.
웹에서 SQLite의 동시성은 일반 플랫폼과 같은 제약을 갖습니다: 각 연결은 한 번에 하나의 트랜잭션만 실행할 수 있습니다. 브라우저는 Wasm을 포함해 직접적인 멀티스레딩을 제공하지 않지만, 여러 웹 워커를 사용하면 유사한 효과를 얻을 수 있습니다.
여러 탭 간 또는 한 탭 내에서 여러 SQLite 연결을 활용하면 동시 트랜잭션을 지원할 수 있습니다. 하지만 어떤 VFS 구현은 데이터베이스에 배타적 잠금을 요구하여 한 번에 단일 연결만 열 수 있게 하며, 이 경우 동시 트랜잭션은 전혀 지원되지 않습니다. 단일 연결을 모든 활성 탭이 공유해야 합니다. 다른 VFS 구현은 여러 동시 연결을 허용하지만 동시 트랜잭션은 하나만 허용합니다. 또 다른 구현은 쓰기 트랜잭션이 없을 때에 한해 여러 동시 읽기 트랜잭션을 허용합니다.
현재로서는 쓰기 트랜잭션과 동시에 읽기 트랜잭션을 지원하는 구현은 없지만, 향후 OPFS에서 SQLite의 WAL 저널 모드를 사용하면 가능할 여지가 있습니다.
쓰기 트랜잭션과 동시에 읽기 트랜잭션을 지원하려면 WAL 모드가 필요합니다. 이를 위해서는 서로 다른 연결 간 “공유 메모리(shared memory)”를 제공하는 추가 VFS 메서드를 구현해야 합니다.
공유 메모리 없이 WAL 모드를 사용하는 것은 가능하지만, 동시 접근을 막아버리므로 여기서는 도움이 되지 않습니다.
현재 WAL 모드를 직접 구현하는 VFS는 없습니다 [2]. 또한 지금 시점에서는 설령 있더라도 도움이 되지 않는데, 그 이유는:
Chrome 121+에서 readwrite-unsafe 모드가 제공되면서, 서로 다른 웹 워커의 연결들 사이에서 필요한 공유 메모리를 제공하는 일은 여전히 까다롭지만, wa-sqlite는 이제 OPFSPermutedVFS 또는 OPFSAdaptiveVFS로 readwrite-unsafe를 활용한 일부 동시성을 지원합니다(아래 참고).
향후 readwrite-unsafe를 사용해 WAL 모드를 지원하는 구현이 추가된다면 매우 유용할 것입니다.
SQLite 성능은 파일 시스템 연산을 어떻게 구현하느냐와 밀접합니다.
성능을 개선하는 방법은 파일 시스템 레이어에서 하거나, 더 상위 수준의 설정으로 할 수 있습니다.
기본적으로 SQLite는 파일에 대한 일련의 쓰기가 어떤 시점에서든(예: 운영체제 크래시나 전원 손실) 중단될 수 있다고 가정합니다. 롤백 저널은 크래시 후 복구를 위해 사용됩니다.
하지만 일부 파일 시스템은 쓰기 연산 묶음이 “전부 성공하거나 전부 실패”함을 보장할 수 있습니다 — 보통 파일 시스템 자체에 저널 모드를 구현함으로써 가능합니다. SQLite는 이 동작을 활용할 수 있을 때(모든 경우는 아니지만) 롤백 저널이 필요 없는 경우가 많아집니다. 여전히 메모리 내 롤백 저널은 유지하며, 너무 커지면 파일로 저장해야 할 수도 있습니다. 웹에서는 IndexedDB가 동일한 보장을 제공하는 데 사용될 수 있고, 그 결과 꽤 괜찮은 성능 향상을 얻을 수 있습니다.
불행히도 이론상으로는 WAL 모드와 유사한 동시성을 제공할 수도 있지만, SQLite는 현재 이를 지원하지 않습니다. 관련 논의는 여기에서 볼 수 있습니다.
데이터베이스를 exclusive 모드로 잠그면, 열린 동안 단일 연결만 데이터베이스에 접근할 수 있습니다. 이는 트랜잭션에 필요한 잠금 수를 줄여 쓰기 성능을 크게 높일 수 있습니다. PRAGMA locking_mode = EXCLUSIVE로 설정합니다.
이 모드에서는 동시 읽기 트랜잭션이 불가능합니다. 다만 어차피 파일 시스템 구현이 한 번에 하나의 연결만 허용하는 경우(아래의 몇몇 옵션)에는 문제가 되지 않습니다.
기본적으로 SQLite는 트랜잭션이 기반 저장소에 안전하게 영속화되었을 때만 트랜잭션을 승인(acknowledge)합니다. 즉 운영체제 크래시나 전원 장애가 있어도 해당 트랜잭션은 잃지 않아야 합니다.
또한 내구성을 완화한 모드도 제공합니다. 이 모드에서는 운영체제가 크래시하면 승인된 트랜잭션이 영속화되지 않았을 수 있지만, 애플리케이션 크래시에 대해서는 안전합니다. PRAGMA synchronous = NORMAL로 설정합니다. 더 나아가 PRAGMA synchronous = OFF 모드는 파일 시스템을 전혀 기다리지 않지만, 운영체제 크래시 시 데이터베이스 손상을 유발할 수 있습니다.
일부 VFS 구현은 저장소 레이어에 특화된 추가 내구성 완화 옵션을 제공할 수도 있습니다.
exclusive 잠금과 synchronous = OFF(또는 VFS의 동등한 내구성 옵션)을 결합하면, 쓰기 트랜잭션이 파일 시스템을 전혀 기다리지 않고 발생할 수 있어 초당 트랜잭션 수가 훨씬 더 높아질 수 있습니다. 다만 큰 트랜잭션 내부에서의 처리량(throughput)은 이로 인해 크게 바뀌지 않을 것으로 예상됩니다.
OPFS를 사용하면 파일을 “투명하게” 저장할 수 있는데, 이는 영속화 포맷이 SQLite의 전통적인 포맷과 정확히 동일하며 우회 방법이나 추가 메타데이터가 필요 없다는 의미입니다. 장점은 서로 다른 구현 간 상호운용성입니다 — 이미 영속화된 데이터를 잃지 않고 라이브러리를 완전히 교체할 수도 있습니다.
여기서 언급한 구현들은 대체로 저수준이며 SQLite API를 직접 노출합니다. 일반적인 애플리케이션이라면 트랜잭션, 잠금, 커넥션 풀링(선택), 웹 워커(해당 시) 등을 관리하고, 쿼리 및 영속화를 위한 더 상위 API를 제공하는 라이브러리를 사용하는 편이 이상적입니다.
PowerSync에서는 wa-sqlite 위에서 Kysely(타입 안전 쿼리 빌더)와 Drizzle(더 완전한 기능의 ORM)을 지원하는 래퍼 라이브러리를 제공합니다. 현재는 PowerSync SDK 전체를 사용해야 합니다. 커뮤니티에서 유지보수하는 라이브러리도 일부 있습니다:
SQLite는 선택적 확장을 통해 저장 시 암호화(at-rest encryption)를 지원합니다.
상용 SQLite Encryption Extension (SSE)은 sqlite-wasm용 빌드를 지원합니다.
대안으로 커뮤니티 기반 SQLite3 Multiple Ciphers는 sqlite-wasm과 wa-sqlite 모두에서 동작하는 WebAssembly 빌드 안내를 제공합니다. 두 옵션 모두 Wasm 빌드를 수동으로 해야 할 수 있으며, wa-sqlite의 경우 빌드 스크립트를 일부 변경해야 할 수도 있습니다. PowerSync는 Web SDK에 SQLite3 Multiple Ciphers 빌드를 포함하지만, 현재로서는 PowerSync خارج에서 단독 사용을 목적으로 하지는 않습니다.
SQLCipher는 현재 시점에서 공식적으로 Wasm 빌드를 지원하는 것으로 보이지 않습니다.
wa-sqlite는 SQLite의 Wasm 빌드를 제공합니다 — 동기 및 Asyncify 버전 모두 포함합니다. 또한 몇 가지 예제와 다양한 VFS 구현을 제공합니다. 여기서는 영속성 있는 VFS 중 고성능 구현들만 비교합니다.
이 VFS 구현들은 프로덕션 준비 코드를 목표로 하기보다는 예제로 의도되었지만, 실제로는 성능이 매우 잘 나온다는 것을 확인했습니다.
버전 관리된 파일 데이터 블록을 IndexedDB에 영속화합니다. 워커 프로세스 또는 메인 페이지에서 실행할 수 있습니다.
SQLite와 기반 파일 시스템 사이에 IndexedDB 레이어가 추가되지만, 배치-원자적 쓰기 트랜잭션을 사용해 매우 좋은 쓰기 성능을 얻습니다.
Asyncify 또는 JSPI 빌드가 필요합니다. 기본적으로는 한 번에 하나의 트랜잭션만 가능하지만, 설정으로 동시 읽기 트랜잭션을 지원할 수 있습니다.
이 VFS는 PRAGMA synchronous=NORMAL로 설정해 쓰기 트랜잭션당 오버헤드를 줄일 수 있습니다.
파일을 OPFS에 파일 형태로 직접 영속화합니다. 비동기 open 및 read 연산과, write 연산을 위한 동기 접근 핸들을 사용합니다.
Asyncify 또는 JSPI 빌드가 필요합니다. 기본적으로는 한 번에 하나의 트랜잭션만 가능하지만, 설정으로 동시 읽기 트랜잭션을 지원할 수 있습니다. 다만 다른 연결에서 쓰기를 수행할 때 잠재적 문제가 있습니다. Chrome에서는 readwrite-unsafe 모드를 사용해 진정한 동시 읽기가 가능합니다.
이 VFS는 파일 시스템 투명성을 갖추고 있어 sqlite-wasm과 호환됩니다.
OPFSCoopSyncVFS는 동기 접근 핸들을 사용한다는 점에서 AccessHandlePoolVFS와 유사하지만, 다중 동시 연결을 지원하며 파일 시스템 투명성도 갖고 있습니다.
OPFSCoopSyncVFS는 새 접근 핸들이 필요할 때, 작업을 큐에 넣는 동안 VFS가 SQLITE_BUSY 오류를 발생시키는 우회 방법을 사용합니다. JavaScript 측에서는 SQLITE_BUSY 오류가 관찰되면, 파일을 여는 비동기 작업이 끝날 때까지 기다린 다음 SQLite 연산을 재시도합니다.
이 접근은 접근 핸들과 잠금을 여는 과정에만 필요합니다 — 실제 읽기/쓰기는 동기이므로 전체적으로 성능은 좋습니다.
주의할 점으로, 여러 데이터베이스에 걸친 트랜잭션은 지원되지 않습니다.
OPFSCoopSyncVFS는 현재 다중 동시 연결은 지원하지만 동시 트랜잭션은 지원하지 않습니다 — 각 트랜잭션은 배타적 잠금을 사용합니다. 향후 더 나은 동시성이 지원될 수도 있습니다.
이 구현은 여러 파일을 미리 열어 두어, VFS에서 동기적으로 접근할 수 있게 만들며 Asyncify가 필요 없도록 합니다. 즉, 커넥션을 다시 인스턴스화하지 않고 열 수 있는 데이터베이스 수에 사전 설정된 한도가 있지만, 대부분의 애플리케이션에서는 문제가 되지 않을 것입니다.
영속화된 파일은 자동 생성된 이름을 사용하며, 각 파일에는 원래 파일명을 담은 헤더가 있습니다. 이 때문에 저장 포맷은 다른 구현과 호환되지 않습니다. 향후 파일 시스템 투명성을 얻기 위한 아이디어도 있습니다.
동기 접근 핸들은 파일을 배타적으로 잠그므로 동시 트랜잭션은 불가능합니다. 더 나아가, 한 번에 하나의 연결만 파일을 열 수 있습니다. 즉 여러 탭에서 같은 데이터베이스에 접근하려면 단일 워커 프로세스에 MessageChannel을 열어 추가 조율이 필요합니다. 워커는 단일 탭에 연관되므로 그 탭이 닫힐 때 새 워커를 띄우도록 주의해야 합니다. 또한 페이지와 연관 워커가 트랜잭션 중간에 닫히면 문제가 생길 수 있으며, 애플리케이션은 트랜잭션 실패를 처리할 수 있어야 합니다.
참고: 불행히도 SharedWorker는 여러 탭에서 같은 데이터베이스에 접근하는 데 사용할 수 없습니다. OPFS 동기 접근 핸들이 SharedWorker나 ServiceWorker에서는 사용 불가하기 때문입니다.
OPFSPermutedVFS는 쓰기가 활성화되어 있어도 동시 읽기를 지원하는 새로운 VFS입니다. SQLite의 WAL 모드와 유사하게 동작하지만, 로직을 VFS 자체에 구현했습니다. 데이터베이스 파일은 OPFS를 사용하고, 동시성 관리는 IndexedDB로 합니다.
현재 동시 트랜잭션은 Chrome에서만 readwrite-unsafe 모드를 통해 지원됩니다.
2022년 말부터 SQLite는 공식 Wasm 빌드를 제공합니다. 동기 빌드만 지원됩니다. 사용 가능한 VFS 옵션은 다음과 같습니다:
OPFS 기반 VFS는 읽기/쓰기 연산에 동기 접근 핸들을 사용합니다. 여러 연결을 동시에 열 수 있지만, 한 번에 하나의 읽기 또는 쓰기 트랜잭션만 열 수 있습니다.
또한 파일 핸들을 여는 것은 비동기 연산이므로, 이를 동기로 만들기 위해 SharedArrayBuffer + Atomics 우회 방법을 사용합니다. 따라서 SharedArrayBuffer 사용을 위해 COOP 및 COEP 헤더가 필수입니다.
향후 동기 접근 핸들 모드를 활용해 동시 접근을 지원할 수도 있습니다.
이 VFS는 파일 시스템 투명성을 갖추고 있어 wa-sqlite의 OPFS VFS와 상호운용 가능합니다.
또한 Emscripten의 WasmFS를 사용하는 다른 옵션도 있습니다. 유사한 메커니즘을 사용하지만 추가 제약이 있어, OPFS VFS보다 추천하지 않습니다.
OPFS SyncAccessHandle Pool VFS (opfs-sahpool)는 SQLite 3.43.0에서 출시되었습니다. wa-sqlite의 AccessHandlePoolVFS와 같은 아이디어를 사용해 SharedArrayBuffer + Atomics 우회 방법이 필요 없고, 성능도 훨씬 좋습니다. 이 VFS는 데이터베이스 배타적 잠금을 요구하며, 한 번에 하나의 연결만 열 수 있습니다 [3].
absurd-sql 프로젝트는 동기 SQLite 빌드에 SharedArrayBuffer + Atomics 우회 방법을 결합해 IndexedDB 연산을 동기 VFS로 노출합니다.
이 프로젝트는 활발히 유지보수되지 않으며, 참고용으로만 포함합니다.
아래 표에서 “동시 연결(concurrent connections)”은 여러 연결을 동시에 열 수 있지만, 한 번에 하나의 트랜잭션만 활성화될 수 있음을 뜻합니다. “동시 읽기(concurrent reads)”는 쓰기 트랜잭션이 열려 있지 않은 한 여러 읽기 트랜잭션을 동시에 열 수 있음을 의미합니다. 이는 추가 설정 및 애플리케이션 레벨 잠금이 필요할 수 있습니다. 이 글에서는 브라우저 지원 버전들을 실제로 테스트하지 않았습니다. 특히 오래된 버전 범위는 부정확할 수 있습니다.
| Implementation | Storage | Asyncify or JSPI required? | In main page? | In web worker? | Concurrency | File system transparency? | Needs COOP and COEP headers? | Chrome | Safari | Firefox |
|---|---|---|---|---|---|---|---|---|---|---|
sqlite-wasm - opfs | OPFS | No | No | Yes | Concurrent connections | Yes | Yes | 102+ | 17+ | 111+ |
sqlite-wasm - opfs-sahpool | OPFS | No | No | Yes | No | No | No | 108+ | 16.4+ | 111+ |
wa-sqlite - IDBBatchAtomicVFS | IndexedDB | Yes | Yes | Yes | Concurrent reads | No | No | 69+ | 15.4+ | 96+ |
wa-sqlite - OPFSAdaptiveVFS | OPFS | Yes | No | Yes | Concurrent reads | Yes | No | 102+ | 15.4+ | 111+ |
wa-sqlite - AccessHandlePoolVFS | OPFS | No | No | Yes | No | No | No | 108+ | 16.4+ | 111+ |
wa-sqlite - OPFSCoopSyncVFS | OPFS | No | No | Yes | Concurrent connections | Yes | No | 108+ | 16.4+ | 111+ |
wa-sqlite - OPFSPermutedVFS | OPFS + IndexedDB | Yes | No | Yes | Concurrent write + reads | No | No | 108+ | 16.4+ | 111+ |
sql.js - absurd-sql | IndexedDB | No | No | Yes | Not confirmed | No | Yes | 91+ | 15.2+ | 79+ |
2025년 기준으로, wa-sqlite의 OPFSCoopSyncVFS는 범용 VFS로서 좋은 선택입니다. 대용량 데이터베이스에서도 성능이 매우 뛰어나며, 주요 브라우저의 최신 버전에서 모두 동작합니다. 동시성 지원이 부족한 점은 향상된 성능으로 어느 정도 상쇄됩니다.
구형 브라우저 버전을 지원해야 한다면, wa-sqlite의 IDBBatchAtomicVFS가 좋은 폴백 옵션입니다.
SQLite Wasm OPFS 빌드도 파일 시스템 투명성과 좋은 성능을 갖춘 옵션입니다. 다만 COOP 및 COEP 헤더 관련 제약 때문에, 아직은 wa-sqlite 빌드보다 추천하지 않습니다.
PowerSync 클라이언트 SDK에서는 2025년 초부터 wa-sqlite의 OPFSCoopSyncVFS와 IDBBatchAtomicVFS를 모두 지원해 왔습니다. 대부분의 사용 사례에서 둘 다 매우 잘 동작했지만, 다음과 같은 점들이 두드러졌습니다:
1. Chrome과 Edge에서는 일정 시간 비활성 상태가 지속되면 탭이 “중단(suspended)”될 수 있습니다. 어떤 탭의 데이터베이스 워커를 다른 탭들이 공유하고 있다면, 해당 워커에 접근할 수 없게 되어 쿼리가 응답하지 않게 됩니다. 우리는 워커에서 Web Lock을 열린 상태로 유지해 탭이 중단되지 않도록 하는 방식으로 이를 해결했습니다.
이 글을 위해 많은 정정과 추가 디테일을 제공해 준 wa-sqlite의 저자 Roy Hashimoto에게 특별한 감사를 전합니다. 또한 명확화와 업데이트를 위해 연락해 준 Stephan Beal에게도 감사드립니다.
새로운 wa-sqlite VFS 구현, 개선된 브라우저 JSPI 지원, PowerSync에서의 실사용 경험을 반영해 글을 업데이트했습니다. 저장 시 암호화(at-rest encryption) 지원 섹션을 추가했습니다.
브라우저 측 변경 사항:
1. Firefox에서는 여전히 기능 플래그 뒤에 있으며, Asyncify보다 느립니다.
2. Safari는 아직 지원하지 않지만, Safari가 향후 JSPI를 지원할 수 있다는 [정황](https://github.com/WebKit/standards-positions/issues/422)이 있습니다.
2. wa-sqlite는 2024년 7월에 1.0에 도달했으며, 새로운 VFS 구현들이 추가되었습니다.
1. 이제 OPFSPermutedVFS 또는 OPFSAdaptiveVFS로 readwrite-unsafe 모드를 사용해 일부 동시성을 지원합니다(OPFSAdaptiveVFS는 OriginPrivateFileSystemVFS를 대체).
2. 1.0.0 버전에서 IDBBatchAtomicVFS가 재작성되었지만, 여전히 같은 원리를 사용합니다. 내구성 옵션은 더 이상 별도로 제공하지 않고, 표준 PRAGMA synchronous 옵션으로 내구성을 설정합니다.
동시 연결, 동시 트랜잭션, 또는 동시성 없음의 차이를 더 잘 다루도록 글을 업데이트했습니다.
이 글이 2023-07-19에 처음 게시된 이후, 환경에 몇 가지 업데이트가 있었습니다.
브라우저 측 변경 사항:
공식 sqlite3 Wasm 빌드에서는 opfs-sahpool VFS가 SQLite 3.43.0에서 출시되었습니다.
wa-sqlite에서는, 가능한 경우 위 브라우저 기능을 활용할 수 있도록 현재 VFS 구현들의 재작성이 진행 중입니다:
새 VFS 구현에 대한 자세한 내용은 여기에 있습니다.
파일 시스템 투명성과 동시 읽기 지원으로, 새로운 AccessHandlePoolVFS는 대부분의 웹 앱에 훌륭한 기본 선택이 될 것입니다.
여전히 WAL 모드를 지원하는 웹 VFS는 없습니다. 다만 wa-sqlite에는 JavaScript 측에서 유사한 아이디어를 구현해, 쓰기 중에도 동시 읽기를 지원하는 실험적 VFS가 하나 있습니다. 주목할 만한 영역입니다.
ORM 영역에서는 상위 수준 API를 사용할 수 있는 옵션들이 생겼습니다:
요약 표는 이러한 새 옵션들을 반영하도록 업데이트되었습니다.
최초 게시일.