La Alternativa Rust Nativa a DuckDB con Seguridad Empresarial
100% Rust • Delta Lake Native • DataFusion 50.3 • S3-Native OLAP • AWS Glue Catalog
ACID Transactions • Time Travel • CTEs • Window Functions • Query Caching • REFRESH TABLES
Lakehouse Analytics con soporte completo para Delta Lake y formatos abiertos.
OxideDB v1.6.0 incluye soporte nativo para Delta Lake, el formato lakehouse líder con ACID transactions, time travel y schema evolution.
Operaciones atómicas, consistentes, aisladas y duraderas sobre datos lakehouse en S3.
Consulta versiones anteriores de tus datos con DELTA HISTORY para auditoría y rollback.
Evoluciona el schema de tus tablas sin downtime ni migraciones complejas.
-- Registrar tabla Delta Lake desde S3
REGISTER DELTA 's3://bucket/warehouse/sales' AS sales;
-- REGISTER DELTA TABLE sales (Version: 5, Files: 12, 2.3M rows)
-- Consultar normalmente con SQL estándar
SELECT fecha, SUM(monto) as total
FROM sales
WHERE fecha >= '2025-01-01'
GROUP BY fecha;
-- Ver historial de versiones (Time Travel)
DELTA HISTORY sales;
-- version | timestamp | operation | user
-- 5 | 2025-11-25 21:54:14 | WRITE | etl_user
-- 4 | 2025-11-24 15:30:00 | WRITE | etl_user
-- ...OxideDB está optimizado desde cero para cargas de trabajo OLAP (Online Analytical Processing), ofreciendo velocidad sin precedentes para consultas analíticas complejas sobre grandes volúmenes de datos.
REGISTER DELTA para tablas lakehouse con ACID transactions, time travel y schema evolution
ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, FIRST_VALUE, LAST_VALUE, SUM/AVG/COUNT/MIN/MAX OVER con particiones SIMD
Queries directas sobre Parquet/Delta en S3 - DataFusion 50.3 con Arrow 56 para máximo rendimiento
Common Table Expressions (WITH clause) con soporte completo para queries recursivas y no-recursivas
Sistema de seguridad integral con autenticación robusta, cifrado AES-256-GCM, auditoría completa y controles de acceso basados en roles (RBAC).
Control de acceso basado en roles con permisos granulares y jerarquías de usuarios
Cifrado de datos en reposo y en tránsito con 500MB/s de throughput
Registro detallado de todas las operaciones con timestamps precisos
MFA integrado con soporte TOTP y protección contra ataques
Mientras que DuckDB carece de un sistema de seguridad robusto, OxideDB incluye desde el día 1 todas las características de seguridad empresarial necesarias para entornos de producción críticos.
Motor JOIN de última generación con algoritmos Hash y Sort-Merge optimizados. Soporte completo para todos los tipos de JOIN con rendimiento líder en la industria.
Hash tables con FNV-1a, resize dinámico y particionamiento adaptativo para máximo rendimiento
Algoritmos sort-merge para datasets grandes con optimización de memoria y spill-to-disk
INNER, LEFT/RIGHT/FULL OUTER, CROSS, SEMI, ANTI JOINs con optimización específica
-- JOIN complejo con múltiples tablas y condiciones
SELECT
c.nombre, p.categoria, SUM(o.monto) as total_ventas,
RANK() OVER (PARTITION BY p.categoria ORDER BY SUM(o.monto) DESC) as ranking
FROM ordenes o
JOIN clientes c ON o.cliente_id = c.id
AND o.fecha BETWEEN c.fecha_inicio AND c.fecha_fin
AND o.monto > c.limite_credito
JOIN productos p ON o.producto_id = p.id
AND p.activo = true
WHERE o.fecha >= '2025-01-01'
AND c.region IN ('Norte', 'Sur')
GROUP BY c.nombre, p.categoria
HAVING SUM(o.monto) > 50000
ORDER BY total_ventas DESC;
-- Performance: 20M rows/s con Hash JOINs optimizados
-- 47 tests de integración pasando ✅Sin FFI ni C++. Integración directa con aplicaciones Rust para máximo rendimiento y type safety
Formato abierto de la industria, compatible con todo el ecosistema de data analytics
Integración perfecta con Tokio. Operaciones no-bloqueantes para alta concurrencia
Operaciones SIMD AVX-512 para procesar múltiples valores simultáneamente
Backups incrementales y completos integrados. Scheduler automático para data safety
5x más rápido que DuckDB en queries S3. LTO + AVX2 SIMD optimizado para máximo rendimiento
Conecta con cualquier cliente PostgreSQL: psql, DataGrip, DBeaver, pgAdmin sin cambios
Common Table Expressions con recursión, UNION/UNION ALL optimizados para queries complejas
Queries directas sobre Parquet en S3 - 58.8M filas en producción, sub-segundo de latencia
Integración nativa con AWS Glue Data Catalog para descubrimiento automático de tablas y metadata centralizada
Cache LRU con TTL configurable para resultados de queries - Mejora dramática en queries repetitivas
Comando SQL para re-descubrir tablas desde Glue y S3 sin reiniciar el servidor - Sincronización instantánea
Integración nativa con AWS Glue Data Catalog para descubrimiento automático de tablas, metadata centralizada y sincronización instantánea sin reiniciar el servidor.
Lectura automática de metadata desde AWS Glue - Schema, location, formato detectados automáticamente
Comando SQL para sincronizar tablas nuevas desde Glue y S3 - Sin reinicio del servidor
Auto-discovery desde S3 para tablas no registradas en Glue - Cobertura completa
# config.yaml
glue_catalog:
enabled: true
catalog_id: "761018849553"
s3:
enabled: true
region: "us-east-2"
access_key_id: "AKIA..."
secret_access_key: "..."
# OxideDB lee automáticamente desde Glue
# al iniciar y cuando ejecutas REFRESH TABLES-- Sincronizar tablas nuevas desde Glue/S3
REFRESH TABLES;
-- Resultado:
-- REFRESH TABLES completed.
-- Discovered 47 tables in 2.85s
-- Ahora puedes consultar las tablas nuevas
SELECT COUNT(*) FROM nueva_tabla;Con REFRESH TABLES, puedes agregar nuevas tablas a tu data warehouse (usando oxide-etl u otras herramientas) y sincronizarlas en OxideDB instantáneamente sin reiniciar el servidor. Perfecto para pipelines ETL en producción.
HNSW indexes con TurboQuant (ICLR 2026): compresion 8x de embeddings a 3 bits/dim sin perdida de precision. Auto-indexacion en INSERT, vector_search() nativo, 6.7x mas rapido que brute-force. Puro Rust, zero dependencies C/C++.
Basado en el paper de Google Research (ICLR 2026). PolarQuant + QJL comprimen vectores a 3 bits/dim con 8x menos memoria. Near-optimal distortion rate.
SELECT * FROM vector_search('index', '[...]', k) usa HNSW + TurboQuant internamente. 6.7x mas rapido que brute-force cosine_similarity.
Cada INSERT actualiza el indice HNSW + TurboQuant automaticamente. Sin rebuild manual. ID mapping bidireccional para JOINs con la tabla fuente.
PolarQuant — Rotacion random + cuantizacion escalar optimalQJL — Correccion residual 1-bit via Johnson-Lindenstraussvector_search() nativo: HNSW lookup + ID mappingcosine_distance(a, b) — Distancia coseno (0-2)cosine_similarity(a, b) — Similitud coseno (-1 a 1)euclidean_distance(a, b) — Distancia L2l2_distance(a, b) — Alias de euclidean_distanceinner_product(a, b) — Producto punto entre vectoresvector_dims(v) — Dimensionalidad del vectorvector_norm(v) — Norma L2 del vectorparse_vector(text) — JSON string a vector nativo-- Crear indice con TurboQuant (8x compresion)
CREATE INDEX idx_emb ON documents
USING HNSW (embedding)
WITH (distance='cosine',
quantization='turboquant',
bits=3, dimensions=768);
-- Busqueda vectorial via HNSW (6.7x faster)
SELECT * FROM vector_search(
'idx_emb', '[0.1, 0.2, ...]', 10
);
-- JOIN con tabla fuente para obtener datos
SELECT d.content, d.source, v.similarity
FROM vector_search('idx_emb', '[...]', 5) v
JOIN documents d ON d.id = v.id;-- INSERT auto-indexa en HNSW + TurboQuant
INSERT INTO documents
(id, content, embedding, source)
VALUES
('doc_42', 'Texto del chunk...',
'[0.1, 0.2, 0.3, ...]',
'informe.pdf');
-- ^ Vector indexado automaticamente
-- Compresion TurboQuant:
-- 768 dims x f32 = 3,072 bytes
-- 768 dims x 3 bits = 288 bytes (10.7x)
-- Opciones de quantization:
-- 'tq2' = 2 bits (16x compresion)
-- 'tq3' = 3 bits (8x, default)
-- 'tq4' = 4 bits (6.4x, max calidad)TurboQuant (ICLR 2026) implementado en Rust puro. HNSW via hnsw_rs, UDFs con AVX2 auto-vectorizacion. Cross-compila desde cualquier plataforma a Linux musl. vector_search() 6.7x mas rapido que brute-force. Compresion near-optimal: dentro de 2.7x del limite information-teorico.
Tu Data Lakehouse completo en una caja. Sin vendor lock-in.
Workflow Orchestration
Ingesta de Datos
Storage S3-Compatible
Query Engine
Cualquier cliente PostgreSQL
| Característica | Oxide Stack | Snowflake | Databricks | Trino + MinIO |
|---|---|---|---|---|
| Self-hosted | ✓ | ✗ | ✗ | ✓ |
| PostgreSQL Wire Protocol | ✓ | ✗ | ✗ | ✗ |
| Storage propio incluido | ✓ | ✗ | ✗ | Separado |
| ETL integrado | ✓ | $$$ | $$$ | ✗ |
| Costo | Gratis | $$$$ | $$$$ | Infra |
| Vendor Lock-in | Ninguno | Alto | Alto | Bajo |
| Setup | 1 comando | Días | Días | Semanas |
* Datos reales desde Oxidestore (S3 remoto), no disco local. DuckDB no pudo conectarse al mismo endpoint.
* DuckDB requiere implementación externa de seguridad con impacto significativo en performance. OxideDB incluye seguridad nativa con overhead mínimo.
-- OxideDB v1.6.0: Lakehouse Analytics con Delta Lake + S3
-- DataFusion 50.3, Delta Lake 0.29, Arrow 56
-- 1. Registrar tabla Delta Lake desde S3
REGISTER DELTA 's3://bucket/warehouse/sales_delta' AS sales;
-- REGISTER DELTA TABLE sales (Version: 5, Files: 12, 2.3M rows)
-- 2. Sincronizar tablas desde AWS Glue Catalog
REFRESH TABLES;
-- REFRESH TABLES completed. Discovered 47 tables in 2.85s
-- 3. CTE con Window Functions sobre Delta Lake
WITH monthly_sales AS (
SELECT
DATE_TRUNC('month', fecha) as mes,
categoria,
SUM(monto) as ventas_mes,
COUNT(DISTINCT cliente_id) as clientes,
ROW_NUMBER() OVER (PARTITION BY categoria
ORDER BY SUM(monto) DESC) as ranking
FROM sales -- Delta Lake table con ACID transactions
WHERE fecha >= '2025-01-01'
GROUP BY DATE_TRUNC('month', fecha), categoria
)
SELECT mes, categoria, ventas_mes, clientes, ranking
FROM monthly_sales
WHERE ranking <= 10;
-- Ver historial de versiones (Time Travel)
DELTA HISTORY sales;
-- Performance: Sub-segundo sobre millones de filas ⚡
-- Features: Delta Lake ✅ Time Travel ✅ CTEs ✅ Window Functions ✅Soporte completo de sintaxis SQL con optimización basada en costos para OLAP
Integración con Parquet, estructuras de datos columnares y I/O mapeado en memoria
Operaciones CUBE/ROLLUP, funciones de ventana, y agregaciones complejas optimizadas
Ejecutables precompilados listos para usar. Sin compilación, sin dependencias complejas.
# === DESCARGA DIRECTA DE EJECUTABLES ===
# Linux amd64 - Ejecutables precompilados (90MB servidor)
wget https://releases.oxidedb.com/v1.6.0/oxidedb-1.6.0-linux-amd64.tar.gz
tar -xzf oxidedb-1.6.0-linux-amd64.tar.gz
# Instalar en el sistema
sudo cp linux-amd64/oxidedb-server /usr/local/bin/
sudo chmod +x /usr/local/bin/oxidedb-server
# Verificar instalación
oxidedb-server --version
# OxideDB Server v1.6.0 (DataFusion 50.3)
# PostgreSQL wire protocol compatible
# Delta Lake, S3-Native, Window Functions, CTEs, UNION, AWS Glue Catalog# Iniciar OxideDB Server (si se instaló manualmente)
oxidedb-server \
--port 5433 \
--data-dir ./oxidedb-data \
--threads 8
# O usar el servicio del sistema (recomendado)
sudo systemctl start oxidedb
# Servidor listo en localhost:5433
# Compatible con protocolo PostgreSQL# Conectar con CLI
oxidedb-cli --host localhost --port 5433
# Ejecutar consultas OLAP
oxidedb> ATTACH 'ventas.parquet' AS ventas;
oxidedb> SELECT region, SUM(monto)
FROM ventas
GROUP BY region;# Verificar archivos instalados
ls -la /usr/local/bin/oxidedb-server
# Verificar versión
oxidedb-server --version
# OxideDB Server v1.6.0 (DataFusion 50.3)
# PostgreSQL wire protocol compatible
# Delta Lake, S3-Native, Window Functions, CTEs# Conectar con psql (PostgreSQL wire protocol)
psql -h localhost -p 5433 -U oxidedb -d postgres
# Test query con Window Function
SELECT
'OxideDB' as db,
ROW_NUMBER() OVER () as ranking
UNION ALL
SELECT 'Running', 2;
# Salida: db='OxideDB', ranking=1 ✅