Rider's Built-In Database Tool Window for .NET Development

The context-switch cost

You are stepping through a .NET API in Rider and need to verify a row in the database. You switch to SQL Server Management Studio, pgAdmin, or DBeaver, paste a connection string you copied from appsettings.json, run a query, then switch back. The SQL editor has no idea which C# entity maps to which table, so renaming a column means hunting through both the migration and the entity class by hand.

Rider bundles JetBrains DataGrip, a full relational database engine, inside the IDE. For .NET teams using Entity Framework Core, this means connection strings, DbContext classes, and SQL can share one workspace instead of two separate tools.

How Rider discovers your data sources

Rider scans the active solution for connection strings in appsettings.json, user-secrets, and EF Core DbContext classes. When it finds one, it offers to register it as a data source in the Database tool window. This is not magic syncing; it is introspection, meaning Rider reads the live database schema so it can suggest table and column names as you type.

Version assumption: Rider 2024.2 or later, EF Core 5 or later, and a project that builds successfully. Broken builds disable SQL-to-C# navigation and rename propagation until the build is fixed.

Worked example: PostgreSQL with EF Core

1. Open a .NET 8 solution that uses EF Core and PostgreSQL.
2. Add a connection string to appsettings.json:

"ConnectionStrings": {
  "DefaultConnection": "Host=localhost;Database=orders_db;Username=developer;Password=change-me"
}

Open the Database tool window (View → Tool Windows → Database). Rider should list DefaultConnection under the project's data sources. Click it and run Test Connection. If the database is reachable, the schema tree populates with tables and columns.

1. Open Rider's embedded terminal (View → Tool Windows → Terminal) inside the project folder and run:

dotnet ef migrations add AddOrdersTable
dotnet ef database update

Required permissions: the database user must have CREATE TABLE and ALTER privileges. Risk: database update changes the target database. There is no automatic rollback in Rider for an applied migration; keep a backup or prepare a down migration first. Run this against a local or development copy first, not production.

Expected check: expand the schema tree in the Database tool window. The new Orders table should appear without a manual refresh. If it does not, click the refresh icon in the tool window toolbar.

1. Open a database console (right-click the data source → New Console) and run:

SELECT id, order_date, total_amount
FROM "Orders"
ORDER BY order_date DESC
LIMIT 10;

To edit schema, right-click a table → Modify Table. Rename a column, review the generated ALTER TABLE statement in the preview, and apply it. Rider can produce a migration script from that change for version-controlled deployment.

SQL that knows your C# code

With a working build, Rider links SQL objects to EF Core entities. You can place the caret on a table name in the console and navigate to the matching C# property. Renaming a column in the database editor can propagate to the C# entity and the migration, which removes the usual mismatch between schema and code.

This integration depends on scaffolded contexts and a clean build. If the solution has compile errors, the navigation links disappear until you fix them.

Trade-offs and limits

• Relational only: Rider has no native support for MongoDB, Redis, or Cassandra. Third-party plugins exist but are not maintained by JetBrains.
• Large schemas: diagrams with more than roughly 200 tables become slow. Filter by schema or table prefix before generating a diagram.
• Secrets scope: user-secrets integration reads only the active solution's secrets.json. Multi-project solutions with separate secrets per project need manual data-source setup.
• Cloud networking: Azure SQL Managed Instance and Amazon RDS proxies may require explicit IP allow-listing for Rider's built-in SSH tunnel.
• Licensing: Database Tools are included with a Rider subscription. Using DataGrip as a standalone application outside Rider requires a separate DataGrip license.

Practical verification before you switch

Before retiring your standalone SQL client, run this checklist:

1. Create or open a .NET 8 EF Core project with a local PostgreSQL or SQL Server database.
2. Confirm the data source appears automatically after adding the connection string to appsettings.json.
3. Run one migration through Rider's terminal and verify the table appears in the schema tree.
4. Run a parameterized query in the database console and confirm results return without errors.
5. Try renaming a column through Modify Table and inspect the preview SQL before applying.

If Rider cannot introspect your schema, check JetBrains YouTrack for "Rider DB" issues tagged with your database vendor and version. Known limitations vary by provider, so treat the feature set as dependent on your specific driver and server version.

Closing

Rider's database tools will not replace every specialized client—especially for NoSQL stores or massive data warehouses—but for typical .NET relational workflows, they remove the need to leave the IDE for schema inspection, ad-hoc queries, and EF Core migrations. Start with one local database, verify the connection appears automatically, and decide whether the standalone client still earns its place on your taskbar.