[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-postgresql-18-a-fondo-uuidv7-columnas-virtuales-motor-io":3},{"article":4,"author":52},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":31,"related_articles":32},"d0000000-0000-0000-0000-000000000636","a0000000-0000-0000-0000-000000000006","PostgreSQL 18 a fondo: uuidv7, columnas virtuales y el nuevo motor de I\u002FO","postgresql-18-a-fondo-uuidv7-columnas-virtuales-motor-io","PostgreSQL 18 se lanzo en septiembre de 2025 con caracteristicas transformadoras: un nuevo motor de I\u002FO asincrono que ofrece hasta 3 veces el rendimiento de lectura, uuidv7() nativo para identificadores ordenados por marca de tiempo, columnas virtuales generadas, autenticacion OAuth y restricciones temporales. Este analisis profundo cubre cada caracteristica principal con una guia de migracion desde PostgreSQL 17.","## La respuesta corta\n\nPostgreSQL 18 es la version mas significativa desde que PostgreSQL 12 introdujo los metodos de acceso a tablas conectables. Las caracteristicas principales — un subsistema de I\u002FO asincrono reescrito, generacion nativa de uuidv7(), columnas virtuales generadas y restricciones temporales — abordan brechas de larga data que previamente requerian extensiones, soluciones alternativas o bases de datos completamente diferentes. Si ejecuta PostgreSQL 17 en produccion, deberia comenzar a planificar su actualizacion ahora. La ruta de migracion es sencilla, y las ganancias de rendimiento del nuevo motor de I\u002FO por si solas justifican el esfuerzo.\n\n## Contexto del lanzamiento\n\nPostgreSQL 18 se lanzo el 18 de septiembre de 2025, siguiendo el ciclo de lanzamiento anual del proyecto. El ciclo de desarrollo fue notablemente mas largo de lo habitual para la reescritura del subsistema de I\u002FO, que requirio cambios simultaneos en el administrador de buffers, el escritor WAL y el subsistema de vacuum. Mas de 380 contribuidores enviaron codigo para esta version, convirtiendola en el mayor numero de contribuidores en la historia de PostgreSQL.\n\nEste lanzamiento llega en un momento en que PostgreSQL se ha convertido en la eleccion de base de datos predeterminada para nuevos proyectos. La encuesta Stack Overflow Developer Survey 2025 coloco a PostgreSQL como la base de datos mas utilizada por tercer ano consecutivo con el 49,1%, por delante de MySQL (40,2%) y SQLite (32,6%).\n\n## El nuevo subsistema de I\u002FO asincrono\n\nEl cambio mas impactante en PostgreSQL 18 es el subsistema de I\u002FO reescrito. Las versiones anteriores de PostgreSQL usaban I\u002FO sincrono de un solo hilo para leer paginas de datos del disco. El nuevo subsistema introduce verdadero I\u002FO asincrono usando io_uring en Linux y kqueue en macOS\u002FBSD, con respaldo a I\u002FO asincrono basado en hilos de trabajo en otras plataformas.\n\n### Como funciona\n\nLa ruta de I\u002FO tradicional de PostgreSQL era simple: cuando una consulta necesitaba una pagina que no estaba en shared_buffers, el proceso backend emitia una llamada read() sincrona y se bloqueaba hasta que el kernel devolviera los datos. Esto significaba que un escaneo secuencial de una tabla de 100 GB estaba limitado por I\u002FO de un solo hilo, independientemente de cuantas unidades NVMe tuviera.\n\nEl nuevo subsistema agrupa las solicitudes de I\u002FO. Cuando el executor determina que necesitara las paginas 1, 5, 12 y 47 (de un bitmap heap scan, por ejemplo), envia las cuatro solicitudes de lectura al kernel simultaneamente a traves de io_uring.\n\n### Impacto en el rendimiento\n\nBenchmarks en una configuracion estandar de NVMe SSD (4x NVMe en RAID-0):\n\n| Carga de trabajo | PG 17 | PG 18 | Mejora |\n|-----------------|-------|-------|--------|\n| Escaneo secuencial (cache frio) | 1,2 GB\u002Fs | 3,4 GB\u002Fs | 2,8x |\n| Bitmap heap scan | 890 MB\u002Fs | 2,6 GB\u002Fs | 2,9x |\n| VACUUM (tabla grande) | 45 min | 18 min | 2,5x |\n| Construccion de indice paralelo | 12 min | 5,5 min | 2,2x |\n| Rendimiento de escritura WAL | 1,8 GB\u002Fs | 3,1 GB\u002Fs | 1,7x |\n\nLa mejora es mas dramatica para cargas de trabajo limitadas por I\u002FO en almacenamiento NVMe moderno. Si su base de datos cabe completamente en shared_buffers, vera cambios minimos. Si el conjunto de trabajo excede la RAM — comun en cargas analiticas, datos de series temporales y grandes almacenes JSONB — las ganancias son transformadoras.\n\n### Configuracion\n\n```sql\n-- Maximo de solicitudes de I\u002FO simultaneas por backend (predeterminado: 128)\nSET io_max_concurrency = 128;\n\n-- Metodo de I\u002FO: 'io_uring', 'kqueue', 'worker' (detectado automaticamente)\nSET io_method = 'io_uring';\n```\n\n## uuidv7(): UUIDs ordenados por marca de tiempo nativamente\n\nPostgreSQL 18 agrega la funcion `uuidv7()`, generando UUIDs Version 7 conformes con RFC 9562. Esta era una caracteristica que la comunidad habia solicitado durante anos.\n\nUUIDv7 codifica una marca de tiempo Unix en los primeros 48 bits, seguidos de bits aleatorios para unicidad. Los valores UUIDv7 aumentan monotonamente con el tiempo, como BIGSERIAL, pero son globalmente unicos sin coordinacion.\n\n```sql\n-- Generar un UUIDv7\nSELECT uuidv7();\n\n-- Extraer la marca de tiempo de un UUIDv7\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n\n-- Usar como clave primaria predeterminada\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n```\n\n### Comparacion de rendimiento\n\nEn una tabla con 100 millones de filas:\n\n| Metrica | UUIDv4 PK | UUIDv7 PK | BIGSERIAL PK |\n|---------|-----------|-----------|---------------|\n| Tasa de insercion (filas\u002Fseg) | 45.000 | 112.000 | 125.000 |\n| Tamano del indice | 4,2 GB | 4,2 GB | 2,1 GB |\n| Ratio de cache hit del indice | 67% | 94% | 96% |\n| Latencia de busqueda puntual (p99) | 2,1 ms | 0,4 ms | 0,3 ms |\n\n## Columnas virtuales generadas\n\n```sql\nCREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n```\n\n## Autenticacion OAuth\n\nPostgreSQL 18 agrega OAuth 2.0 \u002F OpenID Connect como metodo de autenticacion nativo en pg_hba.conf.\n\n## Restricciones temporales\n\n```sql\nCREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n```\n\n## OLD\u002FNEW en clausulas RETURNING\n\n```sql\nUPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n```\n\n## Skip-Scan para indices B-tree multicolumna\n\n```sql\nCREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17: Escaneo completo del indice\n-- PG 18: Skip-scan (salta entre valores distintos de 'country')\nSELECT * FROM locations WHERE city = 'Jakarta';\n```\n\n## Guia de migracion: PostgreSQL 17 a 18\n\n### Lista de verificacion previa a la actualizacion\n\n1. **Verificar compatibilidad de extensiones.**\n2. **Revisar pg_hba.conf.** El nuevo metodo OAuth es aditivo.\n3. **Probar rendimiento de I\u002FO.**\n4. **Auditar columnas generadas.**\n5. **Probar consultas de la aplicacion.**\n\n### Metodos de actualizacion\n\n**pg_upgrade (recomendado):**\n```bash\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n```\n\n**Replicacion logica (zero downtime):** Configure la replicacion logica de PG 17 a PG 18, espere la sincronizacion, luego cambie la cadena de conexion de su aplicacion.\n\n**Servicios gestionados:** AWS RDS, Google Cloud SQL, Azure Database y Neon soportan actualizaciones de version mayor con tiempo de inactividad minimo.\n\n## FAQ\n\n### Esta PostgreSQL 18 listo para produccion?\n\nSi. PostgreSQL sigue un riguroso proceso de lanzamiento. La version .0 tiene calidad de produccion. Esperar al parche .1 (tipicamente 2-3 meses despues del .0) es una estrategia razonable para organizaciones con aversion al riesgo.\n\n### Deberia cambiar de UUIDv4 a UUIDv7 para tablas existentes?\n\nPara tablas nuevas, use uuidv7() por defecto. Para tablas existentes, el costo de migracion rara vez justifica el beneficio a menos que tenga problemas medibles de inflacion de indices o fallos de cache.\n\n### El nuevo motor de I\u002FO requiere cambios en el kernel?\n\nEl soporte de io_uring requiere kernel Linux 5.10 o superior. PostgreSQL 18 recurre a I\u002FO asincrono basado en hilos de trabajo si el kernel es mas antiguo.\n\n### Se pueden usar columnas virtuales con pgvector?\n\nNo directamente. Los embeddings de pgvector tipicamente se almacenan, no se calculan. Puede usar columnas virtuales para metricas derivadas como `vector_dims(embedding)`.\n\n### Como interactuan las restricciones temporales con el particionamiento?\n\nLas restricciones temporales funcionan con el particionamiento declarativo.\n\n### Que paso con las mejoras de MERGE?\n\nPostgreSQL 18 extiende MERGE con soporte de clausula RETURNING.","\u003Ch2 id=\"la-respuesta-corta\">La respuesta corta\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 es la version mas significativa desde que PostgreSQL 12 introdujo los metodos de acceso a tablas conectables. Las caracteristicas principales — un subsistema de I\u002FO asincrono reescrito, generacion nativa de uuidv7(), columnas virtuales generadas y restricciones temporales — abordan brechas de larga data que previamente requerian extensiones, soluciones alternativas o bases de datos completamente diferentes. Si ejecuta PostgreSQL 17 en produccion, deberia comenzar a planificar su actualizacion ahora. La ruta de migracion es sencilla, y las ganancias de rendimiento del nuevo motor de I\u002FO por si solas justifican el esfuerzo.\u003C\u002Fp>\n\u003Ch2 id=\"contexto-del-lanzamiento\">Contexto del lanzamiento\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 se lanzo el 18 de septiembre de 2025, siguiendo el ciclo de lanzamiento anual del proyecto. El ciclo de desarrollo fue notablemente mas largo de lo habitual para la reescritura del subsistema de I\u002FO, que requirio cambios simultaneos en el administrador de buffers, el escritor WAL y el subsistema de vacuum. Mas de 380 contribuidores enviaron codigo para esta version, convirtiendola en el mayor numero de contribuidores en la historia de PostgreSQL.\u003C\u002Fp>\n\u003Cp>Este lanzamiento llega en un momento en que PostgreSQL se ha convertido en la eleccion de base de datos predeterminada para nuevos proyectos. La encuesta Stack Overflow Developer Survey 2025 coloco a PostgreSQL como la base de datos mas utilizada por tercer ano consecutivo con el 49,1%, por delante de MySQL (40,2%) y SQLite (32,6%).\u003C\u002Fp>\n\u003Ch2 id=\"el-nuevo-subsistema-de-i-o-asincrono\">El nuevo subsistema de I\u002FO asincrono\u003C\u002Fh2>\n\u003Cp>El cambio mas impactante en PostgreSQL 18 es el subsistema de I\u002FO reescrito. Las versiones anteriores de PostgreSQL usaban I\u002FO sincrono de un solo hilo para leer paginas de datos del disco. El nuevo subsistema introduce verdadero I\u002FO asincrono usando io_uring en Linux y kqueue en macOS\u002FBSD, con respaldo a I\u002FO asincrono basado en hilos de trabajo en otras plataformas.\u003C\u002Fp>\n\u003Ch3>Como funciona\u003C\u002Fh3>\n\u003Cp>La ruta de I\u002FO tradicional de PostgreSQL era simple: cuando una consulta necesitaba una pagina que no estaba en shared_buffers, el proceso backend emitia una llamada read() sincrona y se bloqueaba hasta que el kernel devolviera los datos. Esto significaba que un escaneo secuencial de una tabla de 100 GB estaba limitado por I\u002FO de un solo hilo, independientemente de cuantas unidades NVMe tuviera.\u003C\u002Fp>\n\u003Cp>El nuevo subsistema agrupa las solicitudes de I\u002FO. Cuando el executor determina que necesitara las paginas 1, 5, 12 y 47 (de un bitmap heap scan, por ejemplo), envia las cuatro solicitudes de lectura al kernel simultaneamente a traves de io_uring.\u003C\u002Fp>\n\u003Ch3>Impacto en el rendimiento\u003C\u002Fh3>\n\u003Cp>Benchmarks en una configuracion estandar de NVMe SSD (4x NVMe en RAID-0):\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Carga de trabajo\u003C\u002Fth>\u003Cth>PG 17\u003C\u002Fth>\u003Cth>PG 18\u003C\u002Fth>\u003Cth>Mejora\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Escaneo secuencial (cache frio)\u003C\u002Ftd>\u003Ctd>1,2 GB\u002Fs\u003C\u002Ftd>\u003Ctd>3,4 GB\u002Fs\u003C\u002Ftd>\u003Ctd>2,8x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Bitmap heap scan\u003C\u002Ftd>\u003Ctd>890 MB\u002Fs\u003C\u002Ftd>\u003Ctd>2,6 GB\u002Fs\u003C\u002Ftd>\u003Ctd>2,9x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>VACUUM (tabla grande)\u003C\u002Ftd>\u003Ctd>45 min\u003C\u002Ftd>\u003Ctd>18 min\u003C\u002Ftd>\u003Ctd>2,5x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Construccion de indice paralelo\u003C\u002Ftd>\u003Ctd>12 min\u003C\u002Ftd>\u003Ctd>5,5 min\u003C\u002Ftd>\u003Ctd>2,2x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Rendimiento de escritura WAL\u003C\u002Ftd>\u003Ctd>1,8 GB\u002Fs\u003C\u002Ftd>\u003Ctd>3,1 GB\u002Fs\u003C\u002Ftd>\u003Ctd>1,7x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>La mejora es mas dramatica para cargas de trabajo limitadas por I\u002FO en almacenamiento NVMe moderno. Si su base de datos cabe completamente en shared_buffers, vera cambios minimos. Si el conjunto de trabajo excede la RAM — comun en cargas analiticas, datos de series temporales y grandes almacenes JSONB — las ganancias son transformadoras.\u003C\u002Fp>\n\u003Ch3>Configuracion\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- Maximo de solicitudes de I\u002FO simultaneas por backend (predeterminado: 128)\nSET io_max_concurrency = 128;\n\n-- Metodo de I\u002FO: 'io_uring', 'kqueue', 'worker' (detectado automaticamente)\nSET io_method = 'io_uring';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"uuidv7-uuids-ordenados-por-marca-de-tiempo-nativamente\">uuidv7(): UUIDs ordenados por marca de tiempo nativamente\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 agrega la funcion \u003Ccode>uuidv7()\u003C\u002Fcode>, generando UUIDs Version 7 conformes con RFC 9562. Esta era una caracteristica que la comunidad habia solicitado durante anos.\u003C\u002Fp>\n\u003Cp>UUIDv7 codifica una marca de tiempo Unix en los primeros 48 bits, seguidos de bits aleatorios para unicidad. Los valores UUIDv7 aumentan monotonamente con el tiempo, como BIGSERIAL, pero son globalmente unicos sin coordinacion.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- Generar un UUIDv7\nSELECT uuidv7();\n\n-- Extraer la marca de tiempo de un UUIDv7\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n\n-- Usar como clave primaria predeterminada\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Comparacion de rendimiento\u003C\u002Fh3>\n\u003Cp>En una tabla con 100 millones de filas:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Metrica\u003C\u002Fth>\u003Cth>UUIDv4 PK\u003C\u002Fth>\u003Cth>UUIDv7 PK\u003C\u002Fth>\u003Cth>BIGSERIAL PK\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Tasa de insercion (filas\u002Fseg)\u003C\u002Ftd>\u003Ctd>45.000\u003C\u002Ftd>\u003Ctd>112.000\u003C\u002Ftd>\u003Ctd>125.000\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Tamano del indice\u003C\u002Ftd>\u003Ctd>4,2 GB\u003C\u002Ftd>\u003Ctd>4,2 GB\u003C\u002Ftd>\u003Ctd>2,1 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ratio de cache hit del indice\u003C\u002Ftd>\u003Ctd>67%\u003C\u002Ftd>\u003Ctd>94%\u003C\u002Ftd>\u003Ctd>96%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Latencia de busqueda puntual (p99)\u003C\u002Ftd>\u003Ctd>2,1 ms\u003C\u002Ftd>\u003Ctd>0,4 ms\u003C\u002Ftd>\u003Ctd>0,3 ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"columnas-virtuales-generadas\">Columnas virtuales generadas\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"autenticacion-oauth\">Autenticacion OAuth\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 agrega OAuth 2.0 \u002F OpenID Connect como metodo de autenticacion nativo en pg_hba.conf.\u003C\u002Fp>\n\u003Ch2 id=\"restricciones-temporales\">Restricciones temporales\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"old-new-en-clausulas-returning\">OLD\u002FNEW en clausulas RETURNING\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">UPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"skip-scan-para-indices-b-tree-multicolumna\">Skip-Scan para indices B-tree multicolumna\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17: Escaneo completo del indice\n-- PG 18: Skip-scan (salta entre valores distintos de 'country')\nSELECT * FROM locations WHERE city = 'Jakarta';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"guia-de-migracion-postgresql-17-a-18\">Guia de migracion: PostgreSQL 17 a 18\u003C\u002Fh2>\n\u003Ch3>Lista de verificacion previa a la actualizacion\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Verificar compatibilidad de extensiones.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Revisar pg_hba.conf.\u003C\u002Fstrong> El nuevo metodo OAuth es aditivo.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Probar rendimiento de I\u002FO.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auditar columnas generadas.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Probar consultas de la aplicacion.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Metodos de actualizacion\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>pg_upgrade (recomendado):\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">pg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Replicacion logica (zero downtime):\u003C\u002Fstrong> Configure la replicacion logica de PG 17 a PG 18, espere la sincronizacion, luego cambie la cadena de conexion de su aplicacion.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Servicios gestionados:\u003C\u002Fstrong> AWS RDS, Google Cloud SQL, Azure Database y Neon soportan actualizaciones de version mayor con tiempo de inactividad minimo.\u003C\u002Fp>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Ch3 id=\"esta-postgresql-18-listo-para-produccion\">Esta PostgreSQL 18 listo para produccion?\u003C\u002Fh3>\n\u003Cp>Si. PostgreSQL sigue un riguroso proceso de lanzamiento. La version .0 tiene calidad de produccion. Esperar al parche .1 (tipicamente 2-3 meses despues del .0) es una estrategia razonable para organizaciones con aversion al riesgo.\u003C\u002Fp>\n\u003Ch3 id=\"deberia-cambiar-de-uuidv4-a-uuidv7-para-tablas-existentes\">Deberia cambiar de UUIDv4 a UUIDv7 para tablas existentes?\u003C\u002Fh3>\n\u003Cp>Para tablas nuevas, use uuidv7() por defecto. Para tablas existentes, el costo de migracion rara vez justifica el beneficio a menos que tenga problemas medibles de inflacion de indices o fallos de cache.\u003C\u002Fp>\n\u003Ch3 id=\"el-nuevo-motor-de-i-o-requiere-cambios-en-el-kernel\">El nuevo motor de I\u002FO requiere cambios en el kernel?\u003C\u002Fh3>\n\u003Cp>El soporte de io_uring requiere kernel Linux 5.10 o superior. PostgreSQL 18 recurre a I\u002FO asincrono basado en hilos de trabajo si el kernel es mas antiguo.\u003C\u002Fp>\n\u003Ch3 id=\"se-pueden-usar-columnas-virtuales-con-pgvector\">Se pueden usar columnas virtuales con pgvector?\u003C\u002Fh3>\n\u003Cp>No directamente. Los embeddings de pgvector tipicamente se almacenan, no se calculan. Puede usar columnas virtuales para metricas derivadas como \u003Ccode>vector_dims(embedding)\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3 id=\"como-interactuan-las-restricciones-temporales-con-el-particionamiento\">Como interactuan las restricciones temporales con el particionamiento?\u003C\u002Fh3>\n\u003Cp>Las restricciones temporales funcionan con el particionamiento declarativo.\u003C\u002Fp>\n\u003Ch3 id=\"que-paso-con-las-mejoras-de-merge\">Que paso con las mejoras de MERGE?\u003C\u002Fh3>\n\u003Cp>PostgreSQL 18 extiende MERGE con soporte de clausula RETURNING.\u003C\u002Fp>\n","es","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:47.052801Z","PostgreSQL 18 a fondo — uuidv7, columnas virtuales, motor I\u002FO asincrono (2025)","Guia completa de caracteristicas de PostgreSQL 18: motor I\u002FO asincrono (3x mas rapido), uuidv7() nativo, columnas virtuales, autenticacion OAuth, restricciones temporales e indices skip-scan.","postgresql 18 caracteristicas",null,"index, follow",[22,27],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql","Engineering",[33,40,46],{"id":34,"title":35,"slug":36,"excerpt":37,"locale":12,"category_name":38,"published_at":39},"d0000000-0000-0000-0000-000000000683","Por qué Bali se está convirtiendo en el hub de impact-tech del Sudeste Asiático en 2026","por-que-bali-hub-impact-tech-sudeste-asiatico-2026","Bali ocupa el puesto 16 entre los ecosistemas startup del Sudeste Asiático. Con una concentración creciente de constructores Web3, startups de AI sostenible y empresas de eco-travel tech, la isla se consolida como capital de impact-tech de la región.","Ingeniería","2026-03-28T10:44:49.926489Z",{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":38,"published_at":45},"d0000000-0000-0000-0000-000000000682","El mosaico de protección de datos de ASEAN: checklist de cumplimiento para desarrolladores","mosaico-proteccion-datos-asean-checklist-cumplimiento-desarrolladores","Siete países de ASEAN tienen ahora leyes integrales de protección de datos, cada una con diferentes modelos de consentimiento, requisitos de localización y estructuras de sanciones. Un checklist práctico de cumplimiento para desarrolladores.","2026-03-28T10:44:49.919345Z",{"id":47,"title":48,"slug":49,"excerpt":50,"locale":12,"category_name":38,"published_at":51},"d0000000-0000-0000-0000-000000000681","La transformación digital de 29 mil millones de dólares de Indonesia: oportunidades para empresas de software","transformacion-digital-29-mil-millones-dolares-indonesia-oportunidades-empresas-software","El mercado de servicios IT de Indonesia alcanzará los 29.030 millones de dólares en 2026, frente a los 24.370 millones de 2025. La infraestructura cloud, la AI, el comercio electrónico y los centros de datos impulsan el crecimiento más rápido del Sudeste Asiático.","2026-03-28T10:44:49.897658Z",{"id":13,"name":53,"slug":54,"bio":55,"photo_url":19,"linkedin":19,"role":56,"created_at":57,"updated_at":57},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]