🏛️ DOCUMENTO HISTÓRICO — NO ES LA AGENDA OPERATIVA

Este documento fue un ejercicio mental de pensar gabysql como producto comercial: tres caminos A/B/C, ICPs, comparativas, etc. La conclusión honesta tras escribirlo y operar el proyecto durante varios meses es que el proyecto no es comercial y no apunta a serlo.

La agenda real del proyecto vive en AGENDA_INVESTIGACION.md: un marco de aprendizaje + exploración sobre “cómo se vería una DB nativa de la era de los agentes LLM”. No hay clientes, no hay validación externa, y eso está bien — el objetivo es entender bases de datos a fondo, no shipear un producto.

Este texto queda en el repo como artefacto histórico: ayuda a entender qué partes valen la pena pulir técnicamente. No tomes decisiones basadas en este documento. Si la pregunta es “¿qué hago después?”, la respuesta está en AGENDA_INVESTIGACION.md.

Tres caminos posibles para llevar gabysql desde “MVP funcional” a “producto comercial defendible”. Documento estratégico — para decidir, no para ejecutar paso a paso (eso es el PLAN_MAESTRO_GABYSQL.md).

🎯 La pregunta que este documento responde

“¿Qué tan lejos está gabysql de ser una base de datos realmente comercial, y cuál es el camino concreto?”

La respuesta corta: “comercial” no es un punto único, son tres niveles de ambición distintos, con costos, mercados y riesgos muy diferentes. Este documento desarrolla cada uno con el detalle necesario para tomar una decisión informada.

Está basado en los dos documentos estratégicos de docs/tareas_pendientes/:

• gabysql_roadmap_rdbms.pdf — backlog técnico de 40+ épicas para llegar a un RDBMS completo.
• tabla_desafios_bases_datos_priorizada_gabysql.pdf — los 20 desafíos típicos de BDs, scoreados por impacto/frecuencia/dificultad.

Y en el análisis ejecutivo que aterriza esos PDFs en fases reales.

📊 Resumen ejecutivo de los tres caminos

Recomendación del producto: perseguir A primero, decidir B según tracción real con clientes, no perseguir C sin financiamiento explícito o equipo dedicado.

🟢 Camino A — Embebido nicho comercial

El único camino viable para un solo desarrollador. Compite con SQLite en el nicho de aplicaciones Rust nativas que rechazan FFI a C.

🎯 Mercado objetivo

• Aplicaciones de escritorio en Rust (Tauri, egui, Iced) que necesitan persistencia local y prefieren no enlazar libsqlite3.
• Edge / IoT con un solo proceso escribiendo, formato auditable, footprint pequeño.
• Productos integrados (CMS, ERPs verticales, herramientas administrativas) donde “abrir un Postgres completo” sería sobreingeniería.
• Material educativo sobre internals de motores de BD (SO, universidades, bootcamps).

💰 Modelo de negocio realista

🔬 Diferenciador honesto vs SQLite

📋 Lo que falta entregar para A

Total estimado: 24–42 semanas (6–10 meses) de un dev senior full-time.

✅ Criterios GO/NO-GO para considerar A “comercial”

• Una empresa o desarrollador externo lo usa en producción y publica un caso (testimonio o blog post).
• gabybench corre en CI con thresholds que rompen el build ante regresión > 10%.
• El crate está publicado en crates.io con 0.x semver y al menos un release menor.
• Existen drivers oficiales Python + Node.js documentados.
• No hay ningún unsafe no justificado ni dependencia opcional sin ADR.
• La documentación incluye tutorial de migración desde SQLite (los 5 patterns típicos).

⚠️ Riesgos del camino A

🟡 Camino B — Cliente-servidor pequeño

Requiere equipo. No es viable para un solo dev en plazos razonables. Compite con SQLite-as-server o SurrealDB Lite para casos de uso de tooling interno.

🎯 Mercado objetivo

• Tooling interno de empresas medianas (dashboards, ETL ligero, herramientas de soporte) que no quieren mantener un Postgres.
• Prototipos de empresa que necesitan API HTTP + auth + multi-tenancy mínima.
• Apps multi-cliente donde el server vive en el mismo edge que el cliente.

📋 Suma a A

Total: +24–40 semanas adicionales sobre A (1.5–3 años con un equipo de 2-3 devs).

💰 Modelo de negocio en B

✅ Criterios GO/NO-GO

• 3+ clientes pagantes con renewal year-1 ≥ 80%.
• Locking por tabla pasa benchmark con 100 conexiones concurrentes.
• Backup online verificado en una DB de 10 GB+.
• Drivers oficiales en al menos 4 lenguajes con CI propia.

⚠️ Riesgos del camino B

🔴 Camino C — RDBMS comercial competitivo

Realista solo con financiamiento o un equipo dedicado de 4-6 ingenieros senior por 3-5 años. Compite con Postgres, MySQL, TiDB, YugabyteDB, SurrealDB.

🎯 Mercado objetivo

• Reemplazar Postgres / MySQL en producción.
• BDs distribuidas con replicación, HA, sharding.
• Apps con SQL amplio (joins, subqueries, CTEs, window functions).

📋 Suma a B

Total: +120–200 semanas adicionales (≥ 3 años con 4-6 devs senior).

💰 Modelo de negocio en C

✅ Criterios GO/NO-GO para C

• Financiamiento Serie A o equivalente (≥ USD 5M para 18 meses).
• Equipo de al menos 4 devs senior con experiencia en motores de BDs.
• Customer development con 10+ candidatos a cliente design partner antes de comprometerse.
• El producto en estado B tiene tracción comercial real.

⚠️ Riesgos del camino C

🧪 Cómo se ve cada camino en código (ejemplos concretos)

Lo que gabysql ya hace hoy (estado actual del MVP)

-- Setup
CREATE TABLE users (id INT PRIMARY KEY, name TEXT, score FLOAT);
INSERT INTO users (id, name, score) VALUES (1, 'Ana', 9.5);
INSERT INTO users (id, name, score) VALUES (2, 'Beto', 7.0);

-- Lookup por PK (existe)
SELECT * FROM users WHERE id = 1;

-- Range por PK (existe)
SELECT * FROM users WHERE id BETWEEN 1 AND 100 LIMIT 25;

-- DML completo (existe)
UPDATE users SET name = 'Ana M' WHERE id = 1;
DELETE FROM users WHERE id = 2;

-- Índices secundarios (existe)
CREATE INDEX idx_users_name ON users (name);
SELECT * FROM users WHERE name = 'Ana M';   -- usa el índice
DROP INDEX idx_users_name;

Lo que gabysql debe hacer al final del Camino A

-- Constraints declarativas
CREATE TABLE orders (
  id INT PRIMARY KEY,
  customer_id INT NOT NULL,
  email TEXT UNIQUE,
  status TEXT NOT NULL DEFAULT 'pending',
  created_at DATETIME DEFAULT NOW()
);

-- ORDER BY por índice secundario
CREATE INDEX idx_orders_status ON orders (status);
SELECT id, customer_id FROM orders
  WHERE status = 'pending'
  ORDER BY created_at DESC
  LIMIT 50;

-- integrity_check operacional
$ gabysql integrity-check orders.db
ok pages=128 leaves=42 internals=3 indexes=2 crcs=verified

-- Backup verificado
$ gabysql backup orders.db backup-2026-05-04.gabybak
$ gabysql restore backup-2026-05-04.gabybak verified.db
ok rows-restored=12450

Lo que gabysql debe hacer al final del Camino B

# Locking por tabla — concurrencia real
$ ab -n 10000 -c 100 -p insert.json -T application/json \
     -H 'X-Gabysql-Token: secret' \
     http://localhost:8080/exec
# requests/sec mucho mayor que con mutex global

# Authz fina
$ gabysql-cli grant SELECT ON orders TO analyst@local
$ gabysql-cli grant ALL    ON orders TO admin@local

# /metrics Prometheus
$ curl http://localhost:8080/metrics | grep gabysql
gabysql_requests_total{op="select",status="200"} 12450
gabysql_index_lookups_total{table="orders",index="idx_orders_status"} 8201
gabysql_wal_replay_seconds_count 3

Lo que gabysql debe hacer al final del Camino C

-- Joins reales
SELECT u.name, COUNT(o.id) AS pedidos
FROM users u
LEFT JOIN orders o ON o.customer_id = u.id
WHERE o.created_at >= '2026-01-01'
GROUP BY u.name
ORDER BY pedidos DESC
LIMIT 10;

-- EXPLAIN de un plan real
EXPLAIN SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at;
-- Index Scan using idx_orders_status (cost=0.4..125.6 rows=84)
--   Sort: created_at desc

-- Wire protocol Postgres
$ psql "host=localhost port=8432 dbname=orders user=admin"
psql (16.x, server gabysql 1.0)
orders=> SELECT * FROM users LIMIT 1;

🧭 Decisión recomendada hoy

Camino A, paso a paso, sin distracciones.

Es el único que:

• es ejecutable por un dev senior solo,
• compite en un nicho real (no en el océano rojo de “el próximo Postgres”),
• mantiene el diferenciador que ya está en el código (zero-deps, Rust-safety, auditabilidad),
• y permite reevaluar B con datos reales en 12 meses.

El paso 1 concreto del Camino A ya quedó entregado: índices secundarios + WHERE col_indexada = val (ver CHANGELOG.md entrada 2026-05-04).

El paso 2 sugerido: constraints declarativas (NOT NULL, UNIQUE, DEFAULT). Sin esto, ningún caso de uso serio puede confiar el schema al motor.