Conectar una API .NET con PostgreSQL usando Entity Framework te permite reemplazar bases de datos en memoria o SQL Server por una opción robusta y open source. Aquí aprendes el flujo completo: instalar paquetes, configurar la cadena de conexión, generar migraciones y validar todo con Swagger y PgAdmin.
¿Qué paquetes necesitas para usar PostgreSQL en .NET?
Antes de tocar el código, asegúrate de tener listas las dependencias correctas en tu proyecto.
Desde Manage NuGet Packages busca Postgres e instala Npgsql.EntityFrameworkCore.PostgreSQL, el provider que conecta Entity Framework con PostgreSQL [0:14]. Luego verifica que tengas la herramienta de migraciones de Entity Framework instalada globalmente con:
bash
dotnet tool install --global dotnet-ef
Este comando habilita la CLI que vas a usar para generar y aplicar migraciones [0:30].
¿Qué hace Npgsql en .NET? Es el provider oficial que traduce las operaciones de Entity Framework Core al dialecto SQL de PostgreSQL, permitiendo que tu DbContext hable con la base de datos.
¿Cómo configurar la cadena de conexión a Postgres?
La configuración vive en appsettings.json, el archivo donde .NET centraliza los parámetros de tu aplicación.
Agrega una nueva entrada en ConnectionStrings con los datos propios de PostgreSQL [0:48]:
- host: el nombre del servidor.
- database: el nombre de la base de datos.
- username: el usuario de Postgres.
- password: en el ejemplo se usa
12345.
Luego, en Program.cs, registra el contexto con UseNpgsql apuntando a esa cadena de conexión [1:14]. Un detalle clave: no puedes tener dos providers activos al mismo tiempo, así que comenta la línea de SQL Server para dejar solo la configuración de Postgres [1:30].
¿Por qué no sirve la migración anterior?
Si tu proyecto ya tenía un InitialCreate generado para SQL Server, no podrás reutilizarlo. Esa migración contiene tipos específicos como SqlServerIdentity y nvarchar, que son exclusivos de SQL Server [1:48]. Eliminas las migraciones existentes y generas una nueva con el provider de Postgres.
¿Cómo crear y aplicar migraciones para PostgreSQL?
Con la cadena lista y el contexto configurado, llega el turno de Entity Framework para crear el esquema.
Ejecuta el comando para registrar la nueva migración:
bash
dotnet ef migrations add InitialCreate
Si aparece un error de build durante el proceso, compila el proyecto manualmente con Rebuild en Visual Studio y vuelve a lanzar el comando [2:18]. Es un tropiezo común porque la compilación que dispara Entity Framework a veces falla, y el rebuild manual lo soluciona.
Una vez creada la migración, aplica los cambios contra la base de datos:
bash
dotnet ef database update
Como es la primera ejecución, este comando crea la base desde cero en lugar de actualizarla [2:42]. Puede aparecer un mensaje de error de conexión inicial porque la base aún no existe, pero al final verás un done que confirma la ejecución [2:54].
¿Qué diferencia hay entre migrations add y database update? El primero genera el archivo de migración con los cambios pendientes; el segundo ejecuta esos cambios contra la base de datos real.
¿Cómo verificar la conexión con PgAdmin y Swagger?
La validación final tiene dos frentes: revisar la base directamente y probar los endpoints.
Abre PgAdmin 4, la interfaz gráfica más usada para administrar PostgreSQL [3:08]. Haz Refresh sobre el servidor y verás aparecer la base CursosAppDB con las tablas Task y User ya creadas dentro de los esquemas [3:24].
Luego ejecuta tu API y entra a Swagger para probar el flujo completo:
- Autentícate con las credenciales de prueba (usuario Platzi, contraseña
12345).
- Llama al endpoint POST de User con un nombre como Miguel y un email cualquiera, sin enviar el ID porque se genera automáticamente [3:52].
- Ejecuta el GET y confirma que aparece el registro con el ID
1 asignado [4:08].
¿Qué endpoints conviene probar como práctica?
Para dominar el ciclo completo del CRUD, prueba todos los verbos en cada tabla:
- GET para listar y consultar por ID.
- POST para crear nuevos registros.
- PUT o PATCH para actualizar.
- DELETE para eliminar.
Con esto compruebas que Entity Framework Core funciona indistintamente con bases de datos en memoria, SQL Server o PostgreSQL, y que el cambio entre proveedores depende casi por completo de la configuración del DbContext [4:30].
¿Ya migraste alguna API tuya de SQL Server a PostgreSQL? Cuéntame en los comentarios qué provider prefieres y por qué.
