SchipDB — Native C Database Engine

Benchmark real — 1 bilhão de registros

Real benchmark — 1 billion records

NÚMEROS NÃO MENTEM

NUMBERS DON'T LIE

999.999.999 registros. Chaves de 4, 8 e 16 bytes. Inserção sequencial e aleatória. Três operações — criação de índice, busca e varredura completa (list). Mesmo servidor, mesmo conjunto de dados de origem para todos os engines. A e-tree (motor proprietário do SchipDB) contra BerkeleyDB (BTree), LMDB e RocksDB — sem pegadinhas.

999,999,999 records. 4, 8 and 16-byte keys. Sequential and random insertion. Three operations — index creation, search and full scan (list). Same server, same source dataset for every engine. e-tree (SchipDB's proprietary engine) against BerkeleyDB (BTree), LMDB and RocksDB — no tricks.

69,5×

mais rápido criando índice

faster index creation

vs BerkeleyDB — chave 16 bytes aleatória, 1B registros

vs BerkeleyDB — 16-byte random key, 1B records

8,4×

mais rápido na busca

faster random search

vs BerkeleyDB — 1,39M vs 165K buscas/s, chave 16 bytes

vs BerkeleyDB — 1.39M vs 165K searches/s, 16-byte key

9,7×

índice menor em disco

smaller index on disk

vs BerkeleyDB — 5.086 MB vs 49.488 MB, chave 16 bytes sequencial

vs BerkeleyDB — 5,086 MB vs 49,488 MB, 16-byte sequential key

4.159×

menos tempo de kernel (sys)

less kernel (sys) time

0,97s vs 4.020s de sys time na busca — mmap elimina o overhead

0.97s vs 4,020s of sys time in search — mmap eliminates overhead

Criação de índice, inserção aleatória — registros/segundo por tamanho de chave (maior = melhor) Index creation, random insertion — records/second by key size (higher = better)

e-tree (SchipDB)

BerkeleyDB

LMDB

Busca aleatória — operações/segundo por tamanho de chave (maior = melhor) Random search — operations/second by key size (higher = better)

e-tree (SchipDB)

BerkeleyDB

LMDB

Tamanho do índice em disco, inserção sequencial — MB por tamanho de chave (menor = melhor) Index size on disk, sequential insertion — MB by key size (lower = better)

e-tree (SchipDB)

BerkeleyDB

LMDB

RocksDB

Onde o LMDB vence — varredura completa (list) em árvore com inserção aleatória

Where LMDB wins — full scan (list) on a randomly-inserted tree

LMDB k1658.823.529 rec/s

e-tree (SchipDB) k169.433.962 rec/s

BerkeleyDB k166.756.757 rec/s

Com chaves aleatórias, o layout de página do LMDB permite uma varredura sequencial quase pura via mmap — 6,2× mais rápido que a e-tree neste cenário específico. Em compensação, o LMDB perde por larga margem em criação de índice (13,8× mais lento) e em busca aleatória (1,6× mais lento) — e quando a inserção é sequencial, a e-tree varre o mesmo bilhão de registros em 5 segundos (200M rec/s) contra 71,4M rec/s do LMDB. Publicamos os dois lados.

With random keys, LMDB's page layout allows an almost purely sequential mmap scan — 6.2× faster than e-tree in this specific scenario. In exchange, LMDB loses by a wide margin on index creation (13.8× slower) and random search (1.6× slower) — and when insertion is sequential, e-tree scans the same billion records in 5 seconds (200M rec/s) against LMDB's 71.4M rec/s. We publish both sides.

RocksDB — benchmark ainda em andamento

RocksDB — benchmark still in progress

Dos 18 arquivos de teste previstos para o RocksDB (3 operações × 2 modos de inserção × 3 tamanhos de chave), apenas 4 terminaram até agora — todos com chave de 4 e 8 bytes em modo sequencial. O RocksDB é uma LSM-Tree e degrada fortemente sob esse volume: a busca sequencial de 1 bilhão de registros com chave de 4 bytes sozinha levou 19h 36min (70.587s). Nos quatro testes já concluídos, a e-tree venceu por margens entre 40× e 1.177×. Assim que o restante terminar, esta seção será atualizada.

Of the 18 test files expected for RocksDB (3 operations × 2 insertion modes × 3 key sizes), only 4 have finished so far — all with 4 and 8-byte keys in sequential mode. RocksDB is an LSM-Tree and degrades heavily under this volume: the sequential search of 1 billion 4-byte-key records alone took 19h 36min (70,587s). In the four completed tests, e-tree won by margins between 40× and 1,177×. This section will be updated as the rest completes.

RocksDB — busca sequencial, chave 4 bytes, 1B registros

RocksDB — sequential search, 4-byte key, 1B records

e-tree (SchipDB)16.666.666 rec/s

RocksDB14.166 rec/s

Tempo: e-tree 60s vs RocksDB 70.587s (19h36min) — 1.177× mais rápido Time: e-tree 60s vs RocksDB 70,587s (19h36min) — 1,177× faster

RocksDB — criação sequencial, chave 8 bytes, 1B registros

RocksDB — sequential creation, 8-byte key, 1B records

e-tree (SchipDB)11.904.761 rec/s

RocksDB294.464 rec/s

Tempo: e-tree 84s vs RocksDB 3.396s — 40,4× mais rápido Time: e-tree 84s vs RocksDB 3,396s — 40.4× faster

Inserção aleatória (rand) — registros ou operações por segundo, 1 bilhão de registrosRandom insertion (rand) — records or operations per second, 1 billion records
Operação · chave	Operation · key	e-tree	BerkeleyDB	LMDB
Create · 4B	1.150.338	12.478	67.440	pendentepending
Create · 8B	819.672	9.272	50.945	pendentepending
Create · 16B	517.330	7.445	37.545	pendentepending
Search · 4B	1.447.178	177.429	993.048	pendentepending
Search · 8B	1.455.604	172.860	998.003	pendentepending
Search · 16B	1.392.757	165.180	884.173	pendentepending
List · 4B	12.894.916	6.833.204	66.623.736	pendentepending
List · 8B	10.309.278	6.896.552	66.666.666	pendentepending
List · 16B	9.433.962	6.756.757	58.823.529	pendentepending

Inserção sequencial (seq) — registros ou operações por segundo, 1 bilhão de registrosSequential insertion (seq) — records or operations per second, 1 billion records
Operação · chave	Operation · key	e-tree	BerkeleyDB	LMDB
Create · 4B	22.727.272	109.841	119.005	292.056
Create · 8B	11.904.761	107.054	83.843	294.464
Create · 16B	6.711.409	83.878	57.247	pendentepending
Search · 4B	16.666.666	394.166	1.251.564	14.166
Search · 8B	14.084.507	380.083	1.084.598	pendentepending
Search · 16B	7.812.499	334.784	1.016.260	pendentepending
List · 4B	199.999.999	6.849.315	83.333.333	3.344.482
List · 8B	199.999.999	6.896.552	71.428.571	pendentepending
List · 16B	199.999.999	6.756.757	71.428.571	pendentepending

Condições do teste: 999.999.999 registros por rodada · Chaves de 4, 8 e 16 bytes · Inserção sequencial e aleatória (mesmo arquivo de dados de origem reaproveitado por todos os engines) · BerkeleyDB (implementação BTree), LMDB (mapsize 100GB, tamanho real de disco medido) e RocksDB (configuração padrão) · Mesmo servidor Linux, mesma execução ininterrupta · Com chave de 4 bytes (32 bits) a geração aleatória produz ~20% de colisões de aniversário (200.515.165 duplicadas em 999.999.999 tentativas) — mesmo comportamento em todos os engines, mesma base de comparação. Test conditions: 999,999,999 records per run · 4, 8 and 16-byte keys · Sequential and random insertion (same source data file reused across every engine) · BerkeleyDB (BTree implementation), LMDB (100GB mapsize, real disk usage measured) and RocksDB (default configuration) · Same Linux server, same uninterrupted run · With a 4-byte (32-bit) key, random generation produces ~20% birthday-paradox collisions (200,515,165 duplicates out of 999,999,999 attempts) — identical behavior across every engine, same basis for comparison.

Arquitetura

Architecture

DESIGN SEM COMPROMISSO

DESIGN WITHOUT COMPROMISE

Cada decisão de design foi tomada para eliminar overhead. O registro em disco é a struct em memória. Não existe camada entre o código e os dados.

Every design decision was made to eliminate overhead. The on-disk record is the in-memory struct. There is no layer between code and data.

Camadas do sistema

System layers

Aplicação / Interface Web

Application / Web Interface

HTTP nativo, WebSocket, JSON, CGI eficiente

Native HTTP, WebSocket, JSON, efficient CGI

Tfile

Camada de alto nível — schema, eventos, UI, permissões por campo

High-level layer — schema, events, UI, per-field permissions

Algoritmo de indexação proprietário
Proprietary indexing algorithm
40 anos de refinamento. Não é BTree. Supera BerkeleyDB e LMDB em criação e busca com 1 bilhão de registros.
40 years of refinement. Not a BTree. Outperforms BerkeleyDB and LMDB in creation and search across 1 billion records.

Tflat — motor de I/OI/O engine

mmap direto · pthread mutex nativo · recsize fixo → O(1)

direct mmap · native pthread mutex · fixed recsize → O(1)

Sistema de arquivos Linux

Linux filesystem

dados/ + sets/ — separação de dados e schema

data/ + sets/ — data and schema separation

Por que mmap é revolucionário

Why mmap is revolutionary

sys time BerkeleyDB (busca k16 aleatória, 1B registros): 4.020 segundos
sys time SchipDB (mesma busca): 0,97 segundos
→ O SO gerencia o cache. Zero syscall de read/write no caminho crítico — 4.159× menos tempo de kernel. sys time BerkeleyDB (16-byte random search, 1B records): 4,020 seconds
sys time SchipDB (same search): 0.97 seconds
→ The OS manages cache. Zero read/write syscalls on the critical path — 4,159× less kernel time.

Struct = Disco = Memória

Struct = Disk = Memory

O registro em disco tem exatamente o mesmo layout da struct C em memória. Zero serialização, zero parsing. Acesso por ponteiro direto.

The on-disk record has exactly the same layout as the C struct in memory. Zero serialization, zero parsing. Direct pointer access.

Relacionamentos por ponteiro físico

Physical pointer relationships

Listas duplamente encadeadas nativas eliminam JOINs. Navegação O(1) entre pai e filho sem nenhuma query adicional.

Native doubly-linked lists eliminate JOINs. O(1) navigation between parent and child with no additional queries.

Tipos de domínio nativos

Native domain types

CNPJ, CPF, UF, CEP, Fone, Endereço, Grade — validados e armazenados nativamente. Não é VARCHAR genérico.

CNPJ, CPF, UF, ZIP, Phone, Address, Grid — natively validated and stored. Not generic VARCHAR.

Geração automática de código

Automatic code generation

Um array Tvar[] gera automaticamente structs C, .h, .c, relacionamentos, índices e documentação. 4 linhas criam um banco completo.

A single Tvar[] array automatically generates C structs, .h, .c, relationships, indexes and documentation. 4 lines create a complete database.

Proteção de schema por hash

Hash-based schema protection

Qualquer alteração no dataset gera um novo hash SHA256. O banco recusa abertura se o hash não bate — zero corrupção silenciosa de dados.

Any dataset change generates a new SHA256 hash. The database refuses to open if the hash doesn't match — zero silent data corruption.

Início rápido

Quick start

4 LINHAS PARA COMEÇAR

4 LINES TO START

Criar um banco completo com 80+ tabelas, índices e relacionamentos. Sem configuração, sem migrations, sem ORM.

Create a complete database with 80+ tables, indexes and relationships. No config files, no migrations, no ORM.

/* 1. Defina o schema com Tvar[] */
Tvar a_cliente[] = {{},
  {{0,f_null,Ix,  Type_cnpj,  1,0, "cnpj",   "CNPJ"}},
  {{0,f_null,Vw,  Type_string,50,0, "rsoc",   "Razão Social"}},
  {{0,f_null,0,   Type_date,  1,0, "dtcad",  "Data Cadastro"}},
  {{0,f_null,0,   Type_bool,  1,0, "ativo",  "Ativo"}},
  {{0,f_pedido,Lt}}, /* lista de pedidos */
};

/* 2. Crie o banco — 1 chamada, tudo automático */
Tdb_new("meubanco", argv, Tdb_flg_init,
         F_meubanco, N_meubanco, NULL);

/* 3. Abra para produção */
Db = Tdb_open("meubanco", argv, Ok,
               F_meubanco, N_meubanco, dbinit);

/* 4. Acesse — struct = registro em memória */
R.cliente->cnpj = 12345678000190LL;
Tdb_write(P.cliente, Tflat_flg_newrec);

/* Busca por índice — Tkey_for automático */
Tkey_for(P.cliente->f, pkeys, NULL, Ok) {
    printf("%s\n", R.cliente->rsoc);
}

/* Navegação por lista — O(1), sem JOIN */
Tdb_forlist(P.pedido, f_cliente, Tfile_flg_kinc) {
    printf("Pedido: %d\n", R.pedido->recid);
}

/* Interface SQL via dbsql.c */
Tsql_result *r;

r = Tsql_exec(db, "SELECT rsoc, cnpj FROM cliente"
                    " WHERE ativo = 1 LIMIT 100");

r = Tsql_exec(db, "SELECT vendedorid, SUM(val)"
                    " FROM nf GROUP BY vendedorid"
                    " HAVING SUM(val) > 50000");

/* LINK — navegação nativa Lt/Pt */
r = Tsql_exec(db,
  "SELECT cliente.rsoc, pedido.val"
  " FROM cliente LINK pedido"
  " WHERE pedido.val > 1000");

printf("%s\n", Tsql_json(r));
Tsql_free(r);

Defina o schema em C

Define the schema in C

Arrays Tvar[] descrevem campos, tipos, índices e relacionamentos. O gerador automático produz .h e .c com structs nativas, enums e hash de integridade.

Tvar[] arrays describe fields, types, indexes and relationships. The automatic generator produces .h and .c with native structs, enums and an integrity hash.

Crie o banco uma vez

Create the database once

Tdb_new() cria todos os arquivos, índices e relacionamentos em uma chamada. Na instalação do cliente, não em desenvolvimento.

Tdb_new() creates all files, indexes and relationships in one call. At client installation, not in development.

Abra e use

Open and use

Tdb_open() mapeia tudo em memória via mmap. P.tabela, R.tabela, O.tabela — acesso direto, zero overhead de parse.

Tdb_open() maps everything into memory via mmap. P.table, R.table, O.table — direct access, zero parse overhead.

SQL quando precisar

SQL when you need it

O parser SQL nativo (dbsql.c) oferece SELECT, INSERT, UPDATE, DELETE, GROUP BY, HAVING e a extensão LINK para navegação nativa. Saída em JSON.

The native SQL parser (dbsql.c) provides SELECT, INSERT, UPDATE, DELETE, GROUP BY, HAVING and the LINK extension for native navigation. JSON output.

Comparativo técnico

Technical comparison

CONTRA TODOS

AGAINST ALL

SchipDB vs as principais alternativas para sistemas de alta performance.

SchipDB vs the leading alternatives for high-performance systems.

Característica	Feature	SchipDB	PostgreSQL	BerkeleyDB	LMDB	Redis	RocksDB
Serialização de dados	Data serialization	✓ Zero — struct = discoZero — struct = disk	✗ AltaHigh	✗ AltaHigh	~ Baixa (zero-copy)Low (zero-copy)	~ MédiaMedium	✗ AltaHigh
HTTP/WebSocket nativo	Native HTTP/WebSocket	✓ IntegradoIntegrated	✗	✗	✗	✗	✗
Relacionamentos nativos	Native relationships	✓ Ponteiros O(1)O(1) pointers	~ JOIN	✗	✗	✗	✗
ORM necessário	ORM required	✓ NãoNo	✗ SimYes	✗ SimYes	✗ SimYes	✗ SimYes	✗ SimYes
COUNT(*)	COUNT(*)	✓ O(1) — header	~ O(n)	~ O(n)	~ O(n)	✓ O(1)	~ O(n)
Tipos de domínio BR	Brazilian domain types	✓ CNPJ, CPF, UF, CEP...	✗ VARCHAR	✗ VARCHAR	✗	✗	✗
Thread-safe nativo	Native thread-safe	✓ pthread por tabela	✓	~	✓ MVCC	✓	✓
Gerador de código	Code generator	✓ .h + .c + hash	✗	✗	✗	✗	✗
Proteção de schema	Schema protection	✓ Hash SHA256 automático	~ migrations	✗	✗	✗	✗
Autocorreção	Auto-correction	✓ NativaNative	✗	✗	✗	✗	✗
Busca aleatória (1B, k16)	Random search (1B, k16)	1,39M/s	—	165K/s	884K/s	—	pendentepending
Validado em produção financeira	Validated in financial production	✓ 40 anos40 years	✓	~	✓	~	~

White Paper

PARA O MERCADO FINANCEIRO

FOR THE FINANCIAL MARKET

O Problema

The Problem

Sistemas financeiros modernos enfrentam uma contradição fundamental: bancos de dados convencionais foram projetados para flexibilidade, não para performance máxima. Cada transação passa por camadas de serialização, parsing SQL, gerenciamento de buffer pool e syscalls de I/O — overhead invisível que limita o throughput em ordens de grandeza.

Instituições financeiras que exigem milhões de transações por segundo frequentemente constroem soluções proprietárias ou aceitam hardware cada vez mais caro como substituto para eficiência de software.

Modern financial systems face a fundamental contradiction: conventional databases were designed for flexibility, not maximum performance. Every transaction passes through layers of serialization, SQL parsing, buffer pool management and I/O syscalls — invisible overhead that limits throughput by orders of magnitude.

Financial institutions requiring millions of transactions per second frequently build proprietary solutions or accept increasingly expensive hardware as a substitute for software efficiency.

A Solução SchipDB

The SchipDB Solution

SchipDB elimina cada camada desnecessária entre a aplicação e os dados. O registro em disco é idêntico à struct C em memória — mapeado via mmap, acessado por ponteiro direto. Não existe serialização, não existe parser, não existe buffer pool gerenciado por software.

O algoritmo de indexação proprietário, desenvolvido ao longo de 40 anos, opera com uma estrutura de nós endereçados por aritmética de bits — fundamentalmente diferente de BTree. Testado com 1 bilhão de registros e chaves de 4, 8 e 16 bytes contra BerkeleyDB, LMDB e RocksDB: até 69,5× mais rápido na criação de índices, até 8,4× mais rápido nas buscas, com até 4.159× menos tempo de kernel e até 9,7× menos espaço em disco.

SchipDB eliminates every unnecessary layer between the application and data. The on-disk record is identical to the C struct in memory — mapped via mmap, accessed by direct pointer. No serialization, no parser, no software-managed buffer pool.

The proprietary indexing algorithm, developed over 40 years, operates with a node structure addressed by bit arithmetic — fundamentally different from BTree. Tested with 1 billion records and 4, 8 and 16-byte keys against BerkeleyDB, LMDB and RocksDB: up to 69.5× faster index creation, up to 8.4× faster searches, up to 4,159× less kernel time and up to 9.7× less disk space.

Casos de Uso

Use Cases

Sistemas de liquidação: O SchipDB processa até 1,39 milhão de buscas aleatórias por segundo em 1 bilhão de registros indexados — capacidade suficiente para os maiores volumes de liquidação interbancária brasileira.

Registro de transações: Mais de 500 mil inserções indexadas por segundo com chaves aleatórias em bases de 1 bilhão de registros. Em modo sequencial, mais de 6,7 milhões de inserções por segundo.

Consultas em tempo real: Varredura sequencial completa de 1 bilhão de registros em 5 segundos (200 milhões de registros/s) quando a chave é sequencial — para dashboards, relatórios em tempo real e auditoria.

Validado em produção: O SchipDB opera em instituições financeiras brasileiras há décadas, processando folhas de pagamento, notas fiscais, duplicatas e movimentação bancária em produção real.

Settlement systems: SchipDB processes up to 1.39 million random searches per second across 1 billion indexed records — sufficient capacity for the highest Brazilian interbank settlement volumes.

Transaction logging: Over 500 thousand indexed insertions per second with random keys on 1-billion-record datasets. In sequential mode, over 6.7 million insertions per second.

Real-time queries: Full sequential scan of 1 billion records in 5 seconds (200 million records/s) when the key is sequential — for dashboards, real-time reports and auditing.

Production-validated: SchipDB has operated in Brazilian financial institutions for decades, processing payroll, invoices, receivables and bank transactions in real production.

Modelo de Licenciamento

Licensing Model

SchipDB é disponibilizado sob licença comercial. O algoritmo de indexação proprietário permanece protegido — apenas a interface pública (API C, parser SQL, HTTP/WebSocket) é exposta ao licenciado.

Licenças por implantação, por servidor ou por volume de transações. Entre em contato para proposta personalizada.

SchipDB is available under a commercial license. The proprietary indexing algorithm remains protected — only the public interface (C API, SQL parser, HTTP/WebSocket) is exposed to the licensee.

Licenses per deployment, per server or per transaction volume. Contact us for a customized proposal.

69,5×

Mais rápido na indexação

Faster indexing

vs BerkeleyDB, 1B registros, chave aleatória de 16 bytes

vs BerkeleyDB, 1B records, 16-byte random key

1,39M

Buscas/segundo

Searches/second

Busca aleatória em 1 bilhão de registros indexados

Random search across 1 billion indexed records

200M

Leituras seq./segundo

Seq. reads/second

1 bilhão de registros varridos em 5 segundos (chave sequencial)

1 billion records scanned in 5 seconds (sequential key)

Anos em produção financeira

Years in financial production

Validado em sistemas reais de folha, NF-e e cobrança bancária

Validated in real payroll, invoicing and banking collection systems

O BANCO
QUE NÃO
PEDE
DESCULPA THE DATABASE
THAT ASKS
FOR NO
EXCUSES

NÚMEROS NÃO MENTEM

NUMBERS DON'T LIE

RocksDB — benchmark ainda em andamento

RocksDB — benchmark still in progress

DESIGN SEM COMPROMISSO

DESIGN WITHOUT COMPROMISE

4 LINHAS PARA COMEÇAR

4 LINES TO START

CONTRA TODOS

AGAINST ALL

PARA O MERCADO FINANCEIRO

FOR THE FINANCIAL MARKET

PRONTO PARA
PERFORMANCE
REAL?

READY FOR
REAL
PERFORMANCE?

O BANCOQUE NÃOPEDEDESCULPA THE DATABASETHAT ASKSFOR NOEXCUSES

NÚMEROS NÃO MENTEM

NUMBERS DON'T LIE

RocksDB — benchmark ainda em andamento

RocksDB — benchmark still in progress

DESIGN SEM COMPROMISSO

DESIGN WITHOUT COMPROMISE

4 LINHAS PARA COMEÇAR

4 LINES TO START

CONTRA TODOS

AGAINST ALL

PARA O MERCADO FINANCEIRO

FOR THE FINANCIAL MARKET

PRONTO PARAPERFORMANCEREAL?

READY FORREALPERFORMANCE?

O BANCO
QUE NÃO
PEDE
DESCULPA THE DATABASE
THAT ASKS
FOR NO
EXCUSES

PRONTO PARA
PERFORMANCE
REAL?

READY FOR
REAL
PERFORMANCE?