Base principal

Fuente de verdad

PostgreSQL guarda permanentemente todo lo que importa: catálogo, inventario, compras, ventas y los comprobantes legales. Es la única "verdad" del sistema; todo lo demás (la memoria rápida, el buscador) es caché o se deriva de aquí.

Esta página describe el componente. El detalle de cada tabla, campo por campo, vive en el modelo oficial: Las tablas del negocio →

¿Qué es?

Una base de datos relacional PostgreSQL. Cada lectura y escritura del motor pasa por aquí. Guarda el catálogo (producto, variante), el inventario, las compras de importación, las ventas y —sobre todo— los comprobantes electrónicos, que son legales y no pueden vivir en ningún sitio temporal.

Qué guarda

Las tablas reales, en español y con el dominio del negocio. El esquema completo está en el modelo oficial; aquí va el mapa de alto nivel:

Catálogo: producto, variante (el SKU vive aquí), categoria, imagen_producto.

Inventario: almacen y movimiento_inventario. El stock no es una columna: se calcula sumando los movimientos.

Compras / importación: proveedor, orden_compra, embarque, costo_importacion, documento_aduanero, muestra.

Ventas: cliente, pedido, linea_pedido, envio_cliente.

Facturación: comprobante, nota_credito, pago. Lo legal: serie/correlativo, estado SUNAT, XML/CDR.

Equipo: usuario, con su rol.

Por qué el stock se calcula

Una columna stock escrita a mano se desincroniza en cuanto dos operaciones la tocan a la vez. En su lugar, cada entrada (compra) y cada salida (venta) se anota como una fila en movimiento_inventario, y el stock disponible es la suma. Así siempre cuadra y queda auditable: se puede reconstruir de dónde salió cada unidad.

Lo que garantiza

Transacciones (ACID): si una operación falla a mitad, se deshace entera. Nunca queda un pedido sin su línea ni un cobro a medias.

Integridad referencial: las llaves foráneas impiden datos huérfanos (una línea de pedido siempre apunta a una variante que existe).

Índices: búsquedas rápidas por SKU, por documento de cliente, por pedido.

Comprobantes permanentes: lo que SUNAT exige se guarda aquí para siempre, nunca en la memoria rápida.

Respaldos: copia diaria automática para poder recuperar el negocio si algo se rompe.

Para más adelante Fase posterior

Nada de esto hace falta para el piloto (30–50 SKU). Se difiere hasta que el volumen lo justifique:

Réplica en standby y failover: una segunda copia que toma el relevo si el servidor principal cae. Útil cuando una caída cueste dinero por minuto; al inicio, el respaldo diario basta.

Particionamiento / sharding: repartir tablas enormes entre servidores. Solo tiene sentido con millones de filas.

Réplicas de lectura: servidores extra solo para reportes pesados. Más tarde.

Stack

PostgreSQL 16 Django ORM Migraciones de Django pg_trgm (búsqueda) pg_dump (respaldo)

Por qué: PostgreSQL es robusto y maneja bien lo relacional. El ORM de Django permite escribir consultas sin SQL a mano, y sus propias migraciones versionan el esquema (no se usa Alembic, que es de otro ecosistema). La extensión pg_trgm, dentro de la misma base, cubre la búsqueda por ahora —no hace falta un buscador aparte.

La base de datos es el bien más valioso del negocio: respaldo y monitoreo son innegociables. Tres reglas sostienen el modelo —el SKU vive en la variante, el stock se calcula sumando movimientos, y los comprobantes se guardan permanentemente aquí. El detalle campo por campo está en el modelo oficial.