<div align="center">
<img src="https://raw.githubusercontent.com/MPCoreDeveloper/SharpCoreDB/master/SharpCoreDB.jpg" alt="SharpCoreDB 로고" width="180"/>
SharpCoreDB
.NET 11용 고성능 암호화 데이터베이스
임베디드 엔진 + 프로덕션 gRPC 서버를 하나의 생태계에 통합
GitHub stars
NuGet
NuGet downloads
.NET 11
License: MIT
Platforms
Roadmap
SonarCloud Quality Gate
</div>
SharpCoreDB는 SQLite와 같은 단순성, 엔터프라이즈급 보안, 그리고 서버 규모의 기능을 .NET 생태계를 벗어나지 않고 원하는 .NET 팀을 위한 것입니다.
다음과 같은 경우에 사용하세요:
- AES-256-GCM 암호화와 ACID 보장을 갖춘 빠른 임베디드 스토리지
- **gRPC (HTTP/2 + HTTP/3)**를 통한 안전한 네트워크 데이터베이스
- 내장된 벡터 검색, 고급 분석(advanced analytics), 그리고 GraphRAG/그래프 알고리즘
- 이 라인업의 핵심 스위트(1,998개 테스트, 실패 0건, 측정일 2026-10-11), 16개 스위트에 걸친 RC.3 스윕 2,897개 테스트, 그리고 하위 호환성으로 검증된 프로덕션 중심의 스택
현재 릴리스: v2.1.0 (2026-10-10) — .NET 11 / C# 15 라인, master 브랜치 기준. NuGet.org에 게시되었으며 (모든 27개 패키지), master, net11.0 전용입니다. 주요 변경 사항은 다음과 같습니다: 고정 폭 인라인 용량(fixed-width inline capacity)이 두 스토리지 경로 모두에서 기본값으로 24바이트로 제공됩니다 (배치된 다중 행 INSERT 형태에서 +34% 향상 및 추적되는 fair-PK INSERT 비율에서 0.63× → 0.87× 향상). 오버플로우 아레나(overflow arena)가 값당 파일 열기(file open per value) 방식 대신 한 번의 호출로 행 페이로드(row's payloads)를 추가하며, 제어된 인덱스 유지보수(deferred index maintenance)를 갖춘 인플레이스 UPDATE/DELETE는 이제 고정 폭 fair-PK 레이아웃을 업데이트 및 삭제 시 레거시 가변 길이 레이아웃보다 1.2–1.5× 앞서 실행합니다. 이 기능은 **16개 스위트 전반에 걸쳐 2,897개의 테스트(실패 0, 건너뜀 16)**와 쓰기 경로 회귀 게이트(write-path regression gate)에서 검증되었고 (PASSED), 벤치마크는 2026-10-11에 재측정되어 다시 게시되었습니다 (92794084). 모든 비율은 동일 실행 기준입니다: 기본 자세의 fair-PK 형태에서 SharpCoreDB는 SQLite 대비 INSERT 시 1.17× (1.03–1.27) 및 READ 시 1.13× (1.12–1.15) 향상을 보이며, **UPDATE 시 0.53× (0.42–0.53) 및 DELETE 시 0.47× (0.46–0.62)**의 성능을 나타냅니다. 또한 레코드당 암호화 비용은 동일한 고정 폭 아키텍처(fixed-width arm)에서 1.2–1.9× 향상됩니다. 이는 이전에
이전 버전 — net10.0 / C# 14 stable, release/v2.0에 임시 배포: v2.0.0.3 (2026-09-12) — v2.x 엔진 라인에서는 고정 폭 레코드 레이아웃(fixed-width record layout)이 새로운 PK 테이블의 기본값이 되었으며, UPDATE/DELETE 작업은 커밋 시간 툼스톤(commit-time tombstones)과 함께 인플레이스(in-place)로 실행됩니다. 또한 데이터 무결성 강화 배치(data-integrity hardening batch)를 재개하여 사일런트 데이터 손실의 엣지 케이스들(empty-value overflow reload, 단일 파일 고정 폭 아레나 마커, 레거시 1.x delete-after-update purge)을 해결했습니다.
성능 (fair-PK, median-of-3, 최적화된 테스트 환경): UPDATE ~163–245K ops/s, DELETE ~106–172K ops/s, INSERT ~125–152K ops/s, READ ~72–110K ops/s (SQLite 참고: UPDATE ~270–315K, DELETE ~353–420K, INSERT ~186–190K, READ ~95–107K). 정직한 기본 설정(default-config) 주의사항: 순수 기본 설정 구성은 파일 레벨 래퍼가 여전히 AES 작업을 수행하는 동안 개별 레코드 저장 시 암호화가 비활성화되어 있기 때문에(~NoEncryptMode의 근본 원인, P3d), 약 1.3–1.6배 느리게 작동합니다. 전체 참고: 이 블록의 SQLite 참조 값들은 위에 설명된 사전 비교기 수정(pre-comparator-correction) 값을 사용했으므로, 오늘날의 기준이라기보다는 해당 라인의 역사로 이해해 주십시오. 전체 보고서: docs/2.0.0.2_WHAT_CHANGED.md 및 docs/benchmarks/default-config-pk.md.
전체 문서: docs/INDEX.md · 매뉴얼: docs/manual/README.md · 성능: docs/manual/performance.md
🖥️ 그래픽 UI를 찾고 계신가요? SharpCoreDB.Viewer / SharpCoreDB.WebViewer 프로젝트는 독립형 리포지토리 **MPCoreDeveloper/SCDMS**로 이동했습니다. 이 리포지토리에는 이제 엔진, 프로바이더, 서버만 포함되어 있습니다. docs/SCDMS.md를 참조하십시오.
요구 사항 및 두 개의 릴리스 라인
| v2.1.0 — 이 라인(master) | v2.0.0.3 — 보류 중인 라인(release/v2.0) |
|---|
| Target framework | net11.0만 가능 (src 아래의 모든 프로젝트) |
| ... | |
- 솔루션당 한 줄을 선택하세요. 패키지 참조는 라인별로 다릅니다:
net10.0 프로젝트는 2.0.0.x 패키지를 사용하고, net11.0 프로젝트는 2.1.0을 사용합니다. 솔루션 내에서 혼합하지 마세요.
- 빌드를 위해서는 .NET 11 SDK가 필요합니다 —
global.json 고정은 의도적이며, dotnet test는 이 저장소의 러너(runner)가 아닙니다 (Microsoft.Testing.Platform이 그렇습니다; 빌드된 테스트 실행 파일을 실행하거나 docs/INDEX.md를 참조하세요).
- 배포되는 런타임:
win-x64, win-arm64, linux-x64, linux-arm64, osx-x64, osx-arm64.
- SQLite 호환성: 지원하는 SQLite 구문 및 기능은 결코 SQLite보다 적지 않으며, 추가적인 기능이 있어도 괜찮습니다.
INTEGER PRIMARY KEY 구조는 아래 숫자에서의 유사한 비교입니다.
- SIMD 표준: 오직
System.Runtime.Intrinsics만 사용합니다 (AVX-512 → AVX2 → SSE2 → 스칼라), 절대 System.Numerics.Vector<T>를 사용하지 마세요 — .github/SIMD_STANDARDS.md를 참조하세요.
- 속도를 위해 암호화 및 내구성을 희생하는 일은 없습니다: 저장 시 AES-256-GCM, WAL 의미론(semantics), 그리고 충돌 일관성/재개방 왕복 매트릭스는 릴리스 게이트입니다.
SharpCoreDB를 사용하는 이유?
- 하나의 스택, 두 가지 배포 모델: 임베디드 모드 및 서버 모드
- 성능 우선 설계: SIMD 가속, 제로 할당 읽기 경로, 최적화된 쿼리 경로
- 기본 보안(Security by default): TLS 1.2 이상, JWT, 선택적 mTLS, RBAC, 암호화된 단일 파일 저장소
- 현대적인 .NET 11 네이티브: C# 15, 선택적 생태계 패키지, 프로덕션 준비가 된 모듈
간단 비교
| 기능 | SharpCoreDB | LiteDB | SQLite | RavenDB / MongoDB |
|---|
| .NET 네이티브 임베디드 경험 | ✅ 최상급(First-class) | ✅ | ⚠️ 제공자 래퍼를 통한 방식 | ❌ 네트워크 우선(network-first) |
| ... | | | | |
v2.1.0에서 새로워진 점 (현재 릴리스)
v1.x 버전의 벤치마크 격차(읽기/업데이트/삭제 작업에서 SQLite 대비 16~52배 뒤처짐 — 모든 업데이트가 새 행을 추가했기 때문)는 엔진 동작 개선으로 해소되었습니다. 아래 수치는 2026-10-11에 (92794084, v2.1.0 / .NET 11) **fair-PK harness (중앙값 3회 실행, id INTEGER PRIMARY KEY, 오름차순 PK 배치)**에서 재측정된 것이며, 모든 비율은 해당 실행의 SQLite 측과 비교됩니다 — 이 프로젝트는 절대적인 수치보다는 비율을 보고합니다. 그 이유는 SQLite 자체의 기준치가 실행마다 변동하기 때문입니다.
기본 설정(--pk-default) (순수 DatabaseConfig: 암호화 활성화, harness 플래그 없음). 비율은 SharpCoreDB ÷ SQLite이므로 > 1.00x는 SharpCoreDB가 앞서고 있음을 의미합니다; 범위는 쌍으로 매칭된 개별 실행의 범위이며, 1.00x를 가로지르는 값은 해당 셀이 이 박스의 노이즈 안에 있다는 뜻입니다:
| 작업 (ops/s) | SharpCoreDB v2.1.0 (기본값, 암호화됨) | SQLite (동일 실행) | 비율 |
|---|
| INSERT | 204.263 | 174.469 | 1.17x (1.03–1.27) ✅ |
| ... | | | |
참고 사항: 이 내용은 고정 폭 컬럼 기반의 빠른 경로를 따르는 오름차순 PK 배치에 관한 것입니다. 다른 쿼리 형태는 정확하지만 더 느린 일반 경로로 폴백합니다. SQLite의 PK UPDATE/DELETE 참조 작업은 이 시스템에서 약 ~0.80M / ~1.00M ops/s를 기록했습니다. 앞서 발표된 ~270–315K / ~353–420K 참조 값은 하니스가 SQLite 아르(arm)에 행당 명령 및 두 개의 파라미터를 할당하도록 설정되어 측정되었기 때문에 과소평가한 것이며, 이 수치들은 폐기됩니다. 전체 테이블 및 API 계층: 성능 가이드 · docs/BENCHMARK_RESULTS.md. 로드맵: docs/performance/V2_PERFORMANCE_PLAN.md.
영역별로 변경된 헤드라인입니다. 아래 내용은 배포된 2.1.0 패키지에 포함되어 있으며, 이는 2.1.0-RC.3 라인과 해당 태그와 v2.1.0 사이에 추가된 작업 내용을 모두 포함합니다.
저장소 및 레코드 레이아웃
- ⚡ 고정 폭 레코드 레이아웃이 새로운 PK 테이블의 기본값입니다. — 아웃 오브 라인(out-of-line)
.ovf 오버플로우 영역을 가진 상수 스트라이드 레코드를 사용하며, UPDATE/DELETE는 커밋 시간 타임스톤 마커를 이용한 제자리 덮어쓰기 방식입니다 (전체 파일 재작성 없음)
- ⚡ 인라인 용량은 두 저장 경로 모두에서 24바이트로 제공됩니다. — 멀티파일 및 싱글파일(
.scdb) 모두 해당하며, 배치된 다중 행 INSERT 형태에서는 **+34 %**의 개선 효과가 있고 추적되는 공정한 PK(fair-PK) INSERT 비율에서는 **0.63× → 0.87×**의 개선 효과가 있습니다. 파일의 +20% 지점에서는 노이즈 속에 측정된 32개 값으로, 24바이트가 임계점입니다.
- ⚡ 기존 데이터베이스는 첫 쓰기 가능한 열림 시점에 스스로 레코드 레이아웃을 업그레이드합니다. — 재작성(rewrite)이나 내보내기/가져오기가 필요 없으며 형식 파괴(format break)도 없습니다 (용량은 영속화된 레이아웃의 일부입니다).
- ⚡ 싱글파일(
.scdb) 모드가 이제 멀티파일 모드와 동일한 레코드 레이아웃을 사용합니다 (이전에는 그렇지 않았음) 그리고 구성된 인라인 용량을 준수합니다.
- ⚙️
.scdb 성장은 구성 가능합니다. — DatabaseConfig.SingleFileMinExtensionBytes를 통해 최소 1 MiB로 설정할 수 있습니다 (기존 10 MiB).
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
- 🗜️ 단일 파일(
.scdb) 저장용 블록 레벨 Brotli/GZip 압축 — 암호화 전에 적용되고 복호화 후에 제거되는 투명한, 블록별 방식 (#344)
- 🛡️ 엔벨로프 암호화(Envelope encryption) + 전체 저장 데이터 메타데이터 암호화 — 비밀번호 기반 파일별 DEK (PBKDF2-HMAC-SHA256), 암호화된 블록 레지스트리 / FSM / WAL, 키 및 비밀번호 로테이션 API (#341 후속)
- ⚙️ 구성 가능한 메타데이터 영역 크기 지정 —
FsmSizePages / BlockRegistrySizePages / TableDirectorySizePages를 통해 512MB 단일 파일 제한을 제거함 (#345)
SQL 의미론 (SQLite 호환성)
- ⚡ 선언된 컬럼 타입은 SQLite가 처리하는 방식대로 존중됨 —
DOUBLE/FLOAT는 REAL 컬럼, INT/SMALLINT/INT8는 INTEGER 컬럼이며, 단일 타입 맵으로 해결함
- ⚡
WHERE 절 없이 DELETE FROM t를 실행하면 SQLite처럼 모든 행이 삭제됨 — 이전에는 거부되던 기능임
- ⚡ 명시적인 컬럼 목록을 사용한
INSERT는 위치 기반이 아닌 이름 순서로 모든 배치 경로에 기록함
- ⚡ 엔진 내부에
information_schema가 구현되어 있어, 모든 프로토콜에서 이를 처리할 수 있음
- ⚡ 비동기 진입점은 동기 버전과 유사하게 검증됨 —
ExecuteSQLAsync는 검증하고, ExecuteBatchSQLAsync는 호출자의 트랜잭션 내에서 구성함
성능 및 할당 (Performance and allocation)
