¿Alguna vez has sentido que tu base de datos te está ocultando algo? Recientemente, mientras trabajábamos en una migración en la nube, nos topamos con un par de “muros” que son clásicos del ecosistema PostgreSQL.
1. ¿Cómo organiza MySQL los datos?
Aquí está una de las diferencias clave que suele generar confusión cuando alguien pasa de MySQL a PostgreSQL.
En MySQL, la estructura mental es bastante más plana:
- Tienes una instancia o servidor.
- Dentro de ella, tienes varias bases de datos.
- Y dentro de cada base de datos, directamente, las tablas.
Es decir, en el día a día, MySQL se suele percibir como:
Instancia → Base de datos → Tablas
Aunque técnicamente MySQL maneja también el concepto de schema, en la práctica schema y database son equivalentes. Cuando haces USE mi_base_de_datos;, estás entrando en ese contenedor, y a partir de ahí las tablas cuelgan directamente de él.
Por eso, en entornos MySQL, lo normal es pensar en algo así:
mi_app_db.usuariosmi_app_db.rolesmi_app_db.pedidos
No suele existir esa sensación de “las tablas no aparecen porque estoy mirando en el sitio lógico equivocado dentro de la misma base de datos”. Si estás en la base correcta, normalmente ves las tablas correctas.
Diagrama de Estructura y Flujo
+-----------------------------------+
| INSTANCIA MySQL |
| |
| +-----------------------------+ |
| | Base de datos: mi_app_db | |
| | - usuarios | |
| | - roles | |
| | - pedidos | |
| +-----------------------------+ |
| |
| +-----------------------------+ |
| | Base de datos: analytics_db | |
| | - eventos | |
| | - sesiones | |
| +-----------------------------+ |
+-----------------------------------+
La consecuencia práctica
Si vienes de MySQL, tu intuición suele ser esta:
“Me conecto a la base de datos correcta y ya debería ver todas mis tablas.”
Y esa intuición funciona bastante bien en MySQL.
El problema aparece cuando llevas esa misma expectativa a PostgreSQL. Allí, conectarte a la base correcta no siempre es suficiente, porque dentro de esa base todavía puede haber varios niveles lógicos de organización: los esquemas.
Y aquí es donde empieza la confusión.
2. ¿Cómo organiza PostgreSQL los datos?
En PostgreSQL, la organización es más rica y también más fácil de malinterpretar al principio. La estructura habitual es: instancia → bases de datos → esquemas → tablas.
Este es el punto donde muchos desarrolladores que vienen de otros sistemas se confunden. Te conectas, ejecutas \dt (listado de tablas) y… nada. ¿Se han borrado los datos? No. Simplemente están en otro “archivador”.
Para comprender esto, debemos visualizar cómo está estructurado un servidor PostgreSQL. A diferencia de otros motores, Postgres utiliza esquemas como capas de organización interna.
Diagrama de Estructura y Flujo
+-------------------------------------------------------+
| 1. INSTANCIA (Servidor AWS RDS) |
| Endpoint (DB_HOST): mi-cluster-db.xyz.eu-west-1... |
| |
| +---------------------------------------------------+ |
| | 2. BASES DE DATOS (Contenedor Principal) | |
| | | |
| | +-----------------------+ +----------+ | |
| | | mi_app_db (CONECTADO) | | otra_db | | |
| | | | +----------+ | |
| | | +-------------------+ | | |
| | | | 3. ESQUEMAS | | | |
| | | | (Namespaces) | | | |
| | | | | | | |
| | | | [identidad] <-----+----- search_path mira aquí | |
| | | | [public] | | | |
| | | | [inventory] | | | |
| | | | | | | |
| | | | +---------------+ | | | |
| | | | | 4. TABLAS | | | | |
| | | | | (Datos Reales)| | | | |
| | | | | | | | | |
| | | | | {usuarios} <--+------- SELECT * FROM usuarios;| |
| | | | | {roles} | | | | |
| | | | +---------------+ | | | |
| | | +-------------------+ | | |
| | +-----------------------+ | |
| +---------------------------------------------------+ |
+-------------------------------------------------------+
Los 4 niveles clave:
- Instancia: El servidor físico o el clúster RDS. Contiene todas las bases de datos.
- Base de Datos: Contenedores estancos (ej.
mi_app_db). Se cambia con\c. Lo que sucede aquí no es visible desde otra base de datos. - Esquema (Namespaces): “Carpetas” lógicas dentro de la base de datos (ej.
public,identidad). - Tabla: Las estructuras finales que contienen los registros.
Por defecto, muchas instalaciones terminan resolviendo objetos en public, pero en realidad eso depende del search_path.
2. El secreto del search_path
Si tus tablas están en un esquema personalizado como identidad, no las verás con un simple \dt. Para solucionar esto sin tener que escribir nombres largos (identidad.usuarios) todo el tiempo, ajustamos el search_path:
SQL
-- Consultar en qué esquema estamos mirando ahora
SHOW search_path;
-- Cambiar el foco al esquema correcto (mira primero en 'identidad')
SET search_path TO identidad, public;
-- ¡Ahora \dt ya mostrará tus tablas de identidad!
\dt
3. Resumen de comandos “Salvavidas”
\l: Listar todas las bases de datos.\c nombre_db: Conectar/Cambiar de base de datos.\dn: Listar esquemas disponibles.\dt *.*: Listar TODAS las tablas de todos los esquemas.\d tabla: Ver columnas e índices de una tabla.
Dominar la visibilidad de los esquemas y la automatización de credenciales no solo te hace más eficiente, sino que hace tu flujo de trabajo mucho más seguro. ¡Nos vemos en los logs!
¿Te ha ayudado este artículo?
☕ Invítame a un café