Conectar una API .NET con PostgreSQL usando Entity Framework te permite migrar de SQL Server a Postgres cambiando solo la configuración del proveedor y regenerando las migraciones. Si ya trabajas con Entity Framework Core, este flujo te ahorra reescribir tu lógica de acceso a datos.

La idea es simple: instalas el paquete correcto, ajustas la connection string, configuras el DbContext y dejas que Entity Framework cree las tablas por ti. Aquí viene lo interesante: las migraciones que sirven para SQL Server no funcionan en Postgres, y vas a entender por qué.

¿Qué paquete NuGet necesitas para usar PostgreSQL en .NET?

El primer paso es agregar el proveedor de Postgres para Entity Framework Core desde el Manage NuGet Packages.

Buscas e instalas Npgsql.EntityFrameworkCore.PostgreSQL, que es la biblioteca oficial que conecta Entity Framework con Postgres. Sin este paquete, tu DbContext no sabe cómo hablar con la base de datos.

¿Qué es Npgsql? Es el proveedor de datos de PostgreSQL para .NET. Cuando lo combinas con Entity Framework Core, traduce tus consultas LINQ al dialecto SQL que entiende Postgres.

Además, necesitas la herramienta de línea de comandos para manejar migraciones. La instalas globalmente con:

bash dotnet tool install --global dotnet-ef

Si ya la tienes, el comando te lo confirma. Esta herramienta es la que vas a usar para crear y aplicar migraciones desde la terminal.

¿Cómo configurar la connection string de Postgres en appsettings?

En el archivo appsettings.json defines los datos de conexión. A diferencia de SQL Server, Postgres usa una sintaxis con campos explícitos.

Los parámetros que necesitas son:

• host: el nombre del servidor donde corre Postgres.
• database: el nombre de la base de datos a la que te conectas.
• username: el usuario con permisos.
• password: la contraseña, en el ejemplo de la clase es 12345.

Una vez tienes esa cadena, la referencias desde Program.cs. Ahí configuras el DbContext de tu aplicación con el método específico de Postgres.

¿Cómo registrar el DbContext con UseNpgsql?

En Program.cs registras tu AppDbContext y le indicas que use Postgres con el método UseNpgsql, pasándole la connection string que definiste en appsettings.

Un detalle clave: no puedes tener dos proveedores activos al mismo tiempo. Si antes usabas SQL Server, comenta esa línea para dejar solo la configuración de Postgres. Si no, Entity Framework se confunde y rompe.

¿Por qué hay que regenerar las migraciones al cambiar de SQL Server a Postgres?

Las migraciones que creaste para SQL Server contienen tipos específicos de ese motor, como nvarchar o SQL Server Identity, que Postgres no reconoce.

Eso significa que el archivo InitialCreate anterior es inservible. Tienes que borrar la carpeta de migraciones y generar una nueva desde cero apuntando al proveedor de Postgres.

El flujo es:

1. Eliminar las migraciones anteriores y el snapshot.
2. Ejecutar dotnet ef migrations add InitialCreate para crear la migración nueva.
3. Si aparece un error de build, compila manualmente con Rebuild desde Visual Studio.
4. Volver a ejecutar el comando una vez que el proyecto compile sin errores.

¿Por qué falla a veces el build con Entity Framework? Cuando Entity Framework intenta compilar el proyecto internamente, puede chocar con cachés o referencias. Compilar manual con Rebuild limpia el estado y permite que el comando funcione.

¿Cómo aplicar la migración para crear la base de datos?

Con la migración generada, ejecutas dotnet ef database update. Como es la primera vez, este comando no actualiza, sino que crea la base de datos desde cero junto con las tablas definidas en tu modelo.

A veces vas a ver un mensaje de error de conexión durante el proceso, pero la base puede haberse creado igual. Antes de asumir que falló, revisa directamente en el motor.

¿Cómo verificar que las tablas se crearon en PostgreSQL?

La herramienta más usada para inspeccionar bases de datos Postgres es pgAdmin 4. Es una interfaz gráfica que te conecta al servidor y te deja navegar bases de datos, esquemas y tablas.

Dentro de pgAdmin, te conectas al servidor, das Refresh y deberías ver tu base de datos, en el ejemplo CursosAppDB. Al expandir los esquemas encuentras las tablas, en este caso Task y User, que confirman que la migración corrió bien.

Si las tablas están ahí, ya puedes probar tu API con Swagger.

¿Cómo probar los endpoints con Swagger después de conectar Postgres?

Levantas la API y abres Swagger. El flujo de prueba es el mismo que con cualquier otro proveedor.

Pasos para validar el funcionamiento:

• Autenticarte usando las credenciales del proyecto, en el ejemplo Platzi12345.
• Ir al endpoint POST de User y enviar un correo como miguel@email.com sin mandar el ID, porque Postgres lo genera automáticamente.
• Ejecutar el GET para confirmar que el registro aparece en la lista, con su ID asignado en uno.

Si el POST devuelve el registro creado y el GET lo lista, tu API está leyendo y escribiendo correctamente en Postgres.

Como reto, prueba todos los endpoints disponibles: los GET, los POST, y también el Update y el Delete que armaste en clases anteriores. Así juegas con los datos completos y validas cada operación CRUD contra Postgres.

Lo poderoso aquí es que Entity Framework te deja moverte entre una base de datos en memoria, SQL Server o Postgres cambiando configuración, no código. ¿Cuál de los tres proveedores estás usando en tu proyecto y por qué? Cuéntame en los comentarios.