Novedades

Desde el 22 de julio, una variable escrita como ${{db.mi-base.DATABASE_URL}} llegaba a la aplicación TAL CUAL, con las llaves dentro, en vez de con la cadena de conexión. Y lo peor: la comprobación que existe para parar ese despliegue tampoco saltaba, así que el despliegue salía en verde y el fallo aparecía después, en ejecución, con un error que no mencionaba la causa. Si en ese periodo desplegaste algo con este tipo de variables y viste errores de conexión que no encajaban, ésta era la razón, o al menos una razón suficiente. Ya está arreglado y ahora una referencia que no se resuelve DETIENE el despliegue en vez de dejarlo pasar. Si tienes una aplicación desplegada desde julio con estas variables, vuelve a desplegarla para que coja los valores buenos.

/apps/:id/env · /apps/:id/deployments · /manifest

Cada ronda de copia tenía un tiempo asignado más corto que lo que tarda un fichero de un par de gigas, así que ese fichero no podía terminar nunca: se empezaba, se cortaba, se descartaba y se volvía a empezar. Y por fuera parecía que simplemente quedaba cola. Ahora los ficheros grandes se suben por partes (un corte cuesta una parte, no el fichero), el tiempo asignado da de sobra para el mayor, y si algo aun así no cabe se avisa con su nombre y tamaño en vez de reintentarlo en silencio.

El mensaje de error te mandaba a ejecutar un VACUUM. Está medido contra Postgres real y no hace falta: la carga se deshace entera y el espacio vuelve por sí solo en unos segundos, así que si lo mirabas justo al fallar lo veías ocupado y parecía que tu clúster había quedado dañado. No lo está: sigue sirviendo y puedes reintentar sin recrearlo. Mandarte a tocar tu propia base sin necesidad era peor que no decir nada.

/databases/:id/restore-dump

Hasta ahora se copiaban todos, porque nadie había decidido lo contrario. Tiene sentido dejarlo activado para lo que no puedas reconstruir, y apagarlo para lo que sí —versiones de vídeo, cachés, miniaturas—: pagar por guardar dos veces algo que se regenera es coste sin seguro. Al cambiarlo se te dice qué significa, en vez de un «hecho»: apagarlo es aceptar que si se pierde el almacén principal, esos ficheros se pierden.

/buckets/:id

Cuando el almacén de destino responde «ahora no puedo, inténtalo luego» —algo normal y esperado en un almacén compartido—, la copia se interrumpía y se reportaba como avería. Ahora reintenta frenando el ritmo, y si aun así toca esperar, la copia se marca como pendiente y continúa en la pasada siguiente por donde iba. Un aviso menos que no significaba nada, y una copia que termina.

Había un tope de 30 minutos que no aparecía en ninguna parte: la única forma de descubrirlo era construir un volcado, subirlo y esperar. Con él, una base de unos 33 GB simplemente no se podía restaurar por aquí. Ahora el plazo se calcula según el tamaño (unos 170 MB de SQL por minuto, mínimo media hora y máximo seis) y está escrito al lado del tamaño máximo. Si se agota, el error se llama «restore_timeout» y trae el tiempo transcurrido, el límite y lo último que dijo Postgres — antes decía sólo «falló» y el registro llegaba vacío justo en el caso en que más falta hacía.

/databases/:id/restore-dump · /databases/:id/restore-dump/upload-url

Tu volcado pide las extensiones en un esquema propio (así las coloca Supabase), y nosotros las instalábamos en otro. La orden del volcado responde que ha ido bien y no mueve nada, así que el fallo aparecía miles de líneas más tarde culpando a una vista que era correcta, y había que acertar el esquema a mano al pedir la restauración. Ahora se lee del propio volcado qué extensiones necesita y dónde, sin descargarlo. Y si tu volcado declara alguna que no ofrecemos, se te avisa con el nombre exacto —sin bloquear la restauración, porque declararla no significa que dependas de ella— y se te repite en el error si algo falla por eso, en vez de dejarte depurando una tabla que está bien.

/databases/:id/restore-dump

El límite anterior no venía de tu base ni de Postgres, sino de dónde guardábamos el fichero: un disco compartido con el resto del servicio. Ahora los volcados van a la flota de almacenamiento, que tolera perder dos nodos y tiene sitio de sobra. Un volcado comprime del orden de ocho veces, así que 20 GB comprimidos son unos 150 GB de base.

/databases/:id/restore-dump/upload-url · /databases/:id/restore-dump

Los volcados vivían en el mismo disco que otros datos del servicio, así que algo ajeno a ti podía llenarlo y dejarte parado en mitad de la migración —le pasó a un cliente y lo diagnosticó él—. Ahora viven en una flota aparte. Y la comprobación de si cabe mide esa flota, no la máquina que atiende la petición: antes de mudarlos habría dicho que no cabe teniendo sitio, y que sí con el almacén lleno.

/databases/:id/restore-dump/upload-url

Un volcado completo de una base que venía de Supabase trae su propio CREATE SCHEMA sin «IF NOT EXISTS». Con las extensiones pre-sembradas el esquema ya existía y la restauración moría en la línea 32 — después de subir gigabytes, y justo en el caso para el que sirve la pre-siembra. No aparecía en pruebas pequeñas porque un volcado de una sola tabla no lleva esa línea.

/databases/:id/restore-dump

El esquema creado al pre-sembrar quedaba en propiedad del superusuario, así que el usuario de tu aplicación no podía borrarlo — y como el esquema ya existía, todos los reintentos morían igual. La única salida era crear otra base y volver a subir el volcado. Ahora el esquema es tuyo y puedes quitarlo.

/databases/:id/restore-dump

Un volcado es transitorio: se sube, se restaura y deja de servir. Pero no se recogía nunca —ni al terminar ni al borrar la base de destino—, así que el espacio no volvía y no había forma de reclamarlo. Ahora se recoge a diario. Y si no cabe, se te dice ANTES de subir, con cuánto espacio hay y cuánto se reserva, en vez de dejarte gastar la subida y recibir un error del almacén sin explicación.

/databases/:id/restore-dump/upload-url

Sale en tu panel, cuenta en tu consumo, y sus credenciales las emite el producto en vez de entregarlas a mano. Y una credencial ya emitida se pone al día cuando cambia lo que tu organización posee: la llave de ayer ve el almacén de hoy.

/buckets · /storage/keys

Si una variable referencia un recurso que no existe (borrado o renombrado), antes el contenedor recibía el texto de la referencia tal cual, arrancaba «bien» y fallaba en todas sus rutas — y la comprobación de entorno decía que la variable estaba presente y correcta. Ahora el despliegue se para con el nombre de lo que falta, y la comprobación lo marca como referencia sin resolver.

/apps/:id/deployments · /apps/:id/env/verify

Un volcado con un índice de búsqueda vectorial fallaba al final, después de cargar todos los datos, porque Postgres trae 64 MB de memoria de trabajo y no los ajusta al tamaño de la máquina. Ahora se ajusta para esa sesión, en proporción a la memoria del clúster.

/databases/:id/restore-dump

El recuento existe para demostrar que la migración trajo los datos. Un error al contarlos se convertía en una lista vacía, indistinguible de «esta base no tiene tablas»: el trabajo decía «hecho» y enseñaba cero filas. Ahora vacío significa que no hay tablas, y si no se pudo contar se dice con su motivo.

/databases/:id/restore-dump

Antes sólo constaba que había fallado, sin máquina, sin registros y con el mismo motivo genérico siempre. Ahora se guardan la máquina, la imagen que se intentó ejecutar, el estado y el código de salida del contenedor, y sus últimas líneas de registro.

/apps/:id/scale-out · /apps/:id/deployments

Antes hacía falta traer una imagen ya construida. Ahora se construye una vez y todas las réplicas ejecutan exactamente la misma imagen, no una reconstrucción parecida.

/apps/:id/scale-out

Antes esas acciones se atribuían a tu propio usuario, así que no podías distinguir a la plataforma trabajando de un acceso indebido. Ahora figuran como acción del sistema y llevan escrito para qué.

/audit

Un almacén puede vivir en distintas flotas, cada una con su dirección, y la credencial sólo vale en la que viene con ella. La dirección se toma siempre de la respuesta al crear la clave. Cambiar la dirección y la credencial son dos mitades de la misma operación: hacer sólo una deja todos los objetos inaccesibles.

/storage/keys

El conjunto sigue sirviendo con un nodo entero caído, y los objetos ya no comparten disco con el plano de control.