It is different from the existing post, SQL Server Best Practices for Developers and DBAs (2026 Guide). This one is organised by production concern: configuration, indexing and queries, transactions, drivers, security, backups, monitoring and upgrades. Each rule explains the why, states the trade-off and gives a command to verify the result. The guide ends with an anti-patterns table and a production readiness checklist.

Before you start, you need sysadmin access on a test instance and SSMS or sqlcmd. The .NET examples use Microsoft.Data.SqlClient and the Python examples use pyodbc. Support dates, build numbers and default behaviours are correct as of October 2026. Always test every change on a non-production copy first.

Version note: This guide targets SQL Server 2022 (latest CU27, 16.0.4295.3) and SQL Server 2025 (latest CU9, 17.0.5005.3), with Microsoft.Data.SqlClient v7.0.1.

 

In this guide

• SQL Server Best Practices at a Glance
• SQL Server Configuration Best Practices: Memory, MAXDOP, Cost Threshold and tempdb
• Data Modeling and Indexing Best Practices
• Query Optimization and SQL Server Performance Tuning Best Practices
• Transactions, Isolation Levels and Optimized Locking
• Connection Management and Microsoft.Data.SqlClient Best Practices
• SQL Server Security Best Practices: Least Privilege, Injection and Encryption
• SQL Server Backup Best Practices, High Availability and Restore Testing
• Monitoring SQL Server: Wait Stats, Extended Events and Performance Counters
• Patching and Upgrading to SQL Server 2025: What to Check First
• Common Anti-Patterns and SQL Server DBA Production Readiness Checklist
• Key takeaways
• FAQ

SQL Server Best Practices at a Glance

This guide covers production best practices for SQL Server 2022 and SQL Server 2025, from instance configuration and indexing to security, backups, monitoring and upgrades.

The table below is a quick reference for developers, architects and DBAs. Each rule points to the section that explains the reason, so you can jump to the detail when you need it.

Quick Reference Table

How to Read This Guide

Treat every rule as a default, not a law. Where a rule does not apply, the section states the trade-off and the case where you should do something different.

Test each change on a non-production copy and measure before and after.

SQL Server Configuration Best Practices: Memory, MAXDOP, Cost Threshold and tempdb

These instance-level settings decide how SQL Server uses memory, CPU and temporary storage. Most of them ship with defaults that suit a demo machine, not a production server, so review them on every new install, on 2022 and on 2025.

SQL Server Max Server Memory Setting

Cap max server memory on every version. The default is about 2 TB, which means SQL Server will take whatever it can and leave the OS and other processes to fight for the rest.

Current Microsoft docs suggest a starting point of about 75% of the available memory not used by other processes, including other instances on the same host. Leave min server memory at 0. Setup on Windows has suggested a value since SQL Server 2019, so check what it picked.

The older advice was to leave 4-6 GB, or 10-15%, for the OS. A percentage of what is actually available is a better baseline because it already subtracts a second instance, an SSIS service, antivirus or a monitoring agent. A fixed reserve ignores all of them.

If Lock Pages in Memory (LPIM) is granted to the service account, set a specific value. LPIM stops Windows from trimming SQL Server’s memory, so a wrong cap can starve the OS.

MAXDOP: Why OLTP Does Not Automatically Mean MAXDOP

MAXDOP (maximum degree of parallelism) is the number of CPUs one query can use. Some teams say “OLTP means MAXDOP 1”, while Microsoft publishes a NUMA-based rule. They conflict because the first is a workaround for parallelism waits and the second is a general default.

Start from the Microsoft guidance. A NUMA node (Non-Uniform Memory Access node) is a group of processors that share local memory. Keeping a query inside one node avoids slower cross-node memory access. The table below shows the starting values.

For example, a server with two NUMA nodes of 24 logical processors each would start at 12. A server with two nodes of 40 logical processors each would start at 16, because half of 40 is 20 and the cap is 16.

• Mixed workloads: Use ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP so each database gets its own limit.
• One workload that needs a different limit: Create a Resource Governor workload group with its own MAX_DOP.
• MAXDOP 1 server-wide: Avoid it. Parallel index builds and reporting queries lose parallelism, and maintenance windows get longer.

Cost Threshold for Parallelism and Optimize for Ad Hoc Workloads

The default cost threshold for parallelism is 5, which is too low for modern hardware. Small queries go parallel and waste threads on coordination.

Raise it based on observed plan costs. A value in the 25 to 50 range is a reasonable test value, not a rule. After the change, compare CXPACKET and CXCONSUMER waits before and after, and check that your important queries did not slow down.

Enable optimize for ad hoc workloads when the plan cache fills with single-use plans, e.g. an ORM that sends unparameterized text. On first run SQL Server stores only a small plan stub, and the full plan is cached on the second run. The trade-off is one extra compile for queries that do repeat.

tempdb Configuration

Use several data files of equal size, pre-sized, with a fixed growth increment, on fast storage. Autogrow should be an emergency only, not the sizing method.

Many sessions create temporary objects at once, and they all compete for the allocation pages (PFS, GAM, SGAM) in a single file. That shows up as PAGELATCH waits. More files spread the allocations. SQL Server fills files in proportion to free space, so unequal sizes send most of the work to one file.

Use this rule for the file count, which follows Microsoft guidance:

1. If the server has 8 or fewer logical processors, create one data file per logical processor (e.g. 4 logical processors, 4 files).
2. If the server has more than 8 logical processors, start with 8 data files.
3. If PAGELATCH contention on tempdb allocation pages continues with 8 files, add files in multiples of 4, and stop when the contention goes away.

More files than needed do not help and add some overhead, so do not match the core count on a large server.

SQL Server 2025 Additions

• tempdb space governance: Resource Governor can limit tempdb space per workload group. A workload that exceeds its limit is stopped with an error.
• Accelerated Database Recovery in tempdb: Now supported.
• Resource Governor in Standard edition: It has the same functionality as Enterprise. Standard 2025 is limited to the lesser of 4 sockets or 32 cores, and 256 GB of buffer pool per instance.

Storage and OS Settings

Separate data, log and tempdb volumes where your storage design allows it. Put the log on fast storage or RAID 10, because log writes are sequential and every commit waits for them (WRITELOG).

Enable instant file initialization (IFI) by granting the “Perform volume maintenance tasks” privilege to the SQL Server service account. With IFI, data file growth and restores skip zeroing the new space, so they finish much faster.

Log files are different, and the behavior depends on the version. In SQL Server 2019 and earlier, log files are always zero-initialized. In SQL Server 2022 and later, transaction log growth events of up to 64 MB can also use IFI. Larger log growths, and the initial creation of a log file, are still zeroed.

For the versions this guide targets, set the log autogrowth increment to 64 MB or less so that emergency growths are fast. Still pre-size the log to its working size, because a log that grows often creates many virtual log files and slows recovery.

Sample Configuration Script

The example below assumes one instance on a 32 GB server, so 75% is 24576 MB. It also assumes a single NUMA node with 16 logical processors. By the Microsoft rule, a single node with more than 8 logical processors gets MAXDOP 8, and the same layout gives 8 tempdb data files. Adjust all values for your own hardware.

T-SQL

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'max server memory (MB)', 24576;
EXEC sp_configure 'cost threshold for parallelism', 50;
EXEC sp_configure 'optimize for ad hoc workloads', 1;
RECONFIGURE;

-- Run in the user database that needs its own limit.
-- 8 = single NUMA node with 16 logical processors (more than 8, so cap at 8).
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 8;

-- Verify the instance settings
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name IN ('max server memory (MB)',
               'min server memory (MB)',
               'cost threshold for parallelism',
               'optimize for ad hoc workloads');

-- Check the NUMA layout and logical processor count used for MAXDOP and tempdb sizing
SELECT cpu_count FROM sys.dm_os_sys_info;

SELECT node_id, online_scheduler_count
FROM sys.dm_os_nodes
WHERE node_state_desc = N'ONLINE';

-- Check tempdb file layout (expect 8 data files on this 16-processor server)
SELECT name, physical_name,
       size * 8 / 1024 AS size_mb,
       growth, is_percent_growth
FROM sys.master_files
WHERE database_id = 2;

Run the NUMA queries first and change MAXDOP if your layout differs. The last query should show equal size_mb values, a fixed growth in MB and is_percent_growth set to 0 for every data file.

Data Modeling and Indexing Best Practices

Good SQL Server performance starts with the table design, not the server settings. Model the data cleanly, choose small data types, and add only the indexes your queries use. These rules apply to both SQL Server 2022 and 2025.

Model to Third Normal Form First

Start with third normal form (3NF), where each non-key column depends only on the key. Denormalize only when a measured query problem justifies it.

Normalized tables avoid update anomalies, because a customer address lives in one row and not in every order. Rows stay smaller, so more rows fit on a page. Updates touch fewer rows, which means fewer locks.

Use the Narrowest Correct Data Type and Add Constraints

Pick the smallest type that safely holds the data. The clustered index key is carried into every nonclustered index as the row locator, so a wide clustered key makes every nonclustered index larger. Wide columns in any index key also add to index size, buffer pool memory and I/O.

• int vs bigint: Use int unless you expect more than about 2.1 billion rows.
• date vs datetime2: Use date when no time is needed, and datetime2(0) for second precision.
• Strings: Avoid nvarchar(max) for short values. Use a sized type such as nvarchar(100).

Declare primary key, foreign key, unique and check constraints. The optimizer uses them to build better plans, and they reject bad data at the source, before it reaches the application.

Choose a Narrow, Ever-Increasing Clustered Key

Give every table a clustered index on a narrow, unique, ever-increasing key, such as an int IDENTITY column. New rows are appended at the end of the table, and the small key is copied into each nonclustered index.

A random GUID from NEWID() inserts rows at random positions, which causes page splits and fragmentation. A GUID is also 16 bytes, which makes it a wide clustered key. If you need GUIDs, use NEWSEQUENTIALID() as a column default, or keep an identity column as the clustered key and the GUID as a separate unique column.

Design Nonclustered Indexes for Your Queries

Index the columns used in WHERE, JOIN and ORDER BY. Put equality columns first and the range column after them. Use INCLUDE for columns that are only selected, so the index covers the query without key lookups.

Example: a retail site lists one customer’s recent orders, filtering on CustomerId (equality) and OrderDate (range).

T-SQL

CREATE TABLE dbo.Orders
(
    OrderId     int IDENTITY(1,1) NOT NULL,
    CustomerId  int NOT NULL,
    OrderDate   datetime2(0) NOT NULL,
    Status      tinyint NOT NULL,
    TotalAmount decimal(10,2) NOT NULL,
    CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderId),
    CONSTRAINT FK_Orders_Customers FOREIGN KEY (CustomerId)
        REFERENCES dbo.Customers (CustomerId),
    CONSTRAINT CK_Orders_TotalAmount CHECK (TotalAmount >= 0)
);

CREATE NONCLUSTERED INDEX IX_Orders_Customer_Date
ON dbo.Orders (CustomerId, OrderDate)
INCLUDE (Status, TotalAmount);

This creates a narrow clustered key, a foreign key, a check constraint and a covering index for the customer-orders query.

Remove Duplicate and Unused Indexes

Every index slows inserts, updates and deletes and uses storage. Check sys.dm_db_index_usage_stats to find indexes that are written to but never read.

T-SQL

SELECT OBJECT_SCHEMA_NAME(i.object_id) AS SchemaName,
       OBJECT_NAME(i.object_id)        AS TableName,
       i.name                          AS IndexName,
       ISNULL(s.user_seeks, 0)   AS UserSeeks,
       ISNULL(s.user_scans, 0)   AS UserScans,
       ISNULL(s.user_lookups, 0) AS UserLookups,
       ISNULL(s.user_updates, 0) AS UserUpdates
FROM sys.indexes AS i
LEFT JOIN sys.dm_db_index_usage_stats AS s
       ON s.object_id = i.object_id
      AND s.index_id = i.index_id
      AND s.database_id = DB_ID()
WHERE i.type_desc = 'NONCLUSTERED'
  AND i.is_primary_key = 0
  AND i.is_unique_constraint = 0
  AND OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
  AND ISNULL(s.user_seeks, 0) + ISNULL(s.user_scans, 0) + ISNULL(s.user_lookups, 0) = 0
ORDER BY UserUpdates DESC;

This lists nonclustered indexes with no reads, sorted by write cost. The usage counters reset when the instance restarts, so observe a full business cycle (e.g. a month-end close) before dropping anything.

Maintain Statistics First, Fragmentation Second

Update statistics regularly, because the optimizer chooses plans from them. Stale statistics cause bad row estimates and bad plans.

For fragmentation, act on a threshold and not on a blanket schedule. Measure it with sys.dm_db_index_physical_stats, then pick an action from the table below. These numbers are starting points only, so adjust them after you see how your own workload and storage respond.

Ignore small indexes, for example those under about 1,000 pages, because their fragmentation figures are not meaningful and rarely affect performance. Fragmentation matters less on SSD storage, but statistics matter just as much.

SQL Server 2025 Vector Data

The vector data type is generally available in SQL Server 2025. DiskANN vector indexes are still preview only, need the PREVIEW_FEATURES database scoped configuration, and are not recommended for production yet.

Query Optimization and SQL Server Performance Tuning Best Practices

Most SQL Server performance tuning comes down to a few habits: write predicates the optimizer can seek on, return only the data you need, reuse plans, and watch for plan regressions with Query Store.

Write SARGable Predicates

A SARGable predicate (Search ARGument able) lets the engine use an index seek. Wrapping an indexed column in a function forces a scan, because the function must run on every row.

SQL

-- Bad: function on the column, index on OrderDate cannot be used for a seek
SELECT OrderId, TotalAmount
FROM dbo.Orders
WHERE YEAR(OrderDate) = 2026;

-- Good: range on the bare column, index seek is possible
SELECT OrderId, TotalAmount
FROM dbo.Orders
WHERE OrderDate >= '20260101'
  AND OrderDate <  '20270101';

The rewritten query returns the same rows and reads only the matching index range.

Return Less Data, Use Fewer Round Trips

• Select only needed columns: Avoid SELECT *. It reads and sends extra data, and it stops narrow covering indexes from being used.
• SET NOCOUNT ON: Add it at the top of procedures to stop the “rows affected” message after every statement.
• Set-based code: Use one UPDATE ... JOIN instead of a cursor. A cursor processes one row at a time, which costs more CPU and more statements.

Example: a retail nightly job that updates stock for 200,000 products should run one set-based statement, not a loop that fires 200,000 updates.

Handle Parameter Sniffing

Parameterized queries and stored procedures let SQL Server reuse plans. Parameter sniffing means the plan is built for the first parameter value it sees, which can be a poor fit for later values.

On 2022 and later, PSP optimization is the first thing to try when you are on compatibility level 160. It lets one parameterized statement keep more than one plan for different parameter ranges. If it does not cover your query, move down the table.

Use Query Store

Query Store records queries, plans and runtime statistics inside the database. From SQL Server 2022, it is ON by default for new databases. The “enable it” step therefore mostly applies to databases that were upgraded or restored from an older instance, because they keep their earlier setting.

Check which databases still have it off, and turn it on for the ones you care about. Use QUERY_CAPTURE_MODE = AUTO so trivial queries do not fill the store.

SQL

SELECT name, is_query_store_on
FROM sys.databases
WHERE database_id > 4;

This lists user databases and shows whether Query Store is on for each one.

On readable secondary replicas, the defaults differ by version. In SQL Server 2025, Query Store on readable secondaries is on by default. In SQL Server 2022 it was off and needed trace flag 12606.

SQL

ALTER DATABASE SalesDb SET QUERY_STORE = ON
(
    OPERATION_MODE = READ_WRITE,
    QUERY_CAPTURE_MODE = AUTO,
    MAX_STORAGE_SIZE_MB = 1024,
    INTERVAL_LENGTH_MINUTES = 60,
    SIZE_BASED_CLEANUP_MODE = AUTO
);

The sizes above are example values. Adjust them to your workload.

SQL

SELECT TOP (10)
    q.query_id,
    LEFT(qt.query_sql_text, 200) AS query_text,
    SUM(rs.count_executions * rs.avg_duration) / 1000.0 AS total_duration_ms
FROM sys.query_store_query AS q
JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
GROUP BY q.query_id, qt.query_sql_text
ORDER BY total_duration_ms DESC;

This lists the ten queries that consumed the most total time. Durations are stored in microseconds, so the query divides by 1000.

SQL

EXEC sys.sp_query_store_force_plan @query_id = 42, @plan_id = 17;

-- Remove the forced plan when it is no longer needed
EXEC sys.sp_query_store_unforce_plan @query_id = 42, @plan_id = 17;

Replace the IDs with values from the previous query and the Query Store reports.

Test Feedback Features and Compatibility Levels

The optimizer can adjust some settings for a query after it has run, using what it saw on earlier executions. Two feedback features matter most, and each needs a minimum compatibility level.

• Memory grant feedback: Resizes the memory granted to a query when earlier runs got too much or too little, which reduces tempdb spills and wasted memory. Batch mode needs compatibility level 140 or higher. Row mode needs 150 or higher. In SQL Server 2022, the percentile and persisted versions of this feedback need Query Store to be on and in read-write mode.
• DOP feedback: Lowers the degree of parallelism (DOP, the number of threads a query uses) for parallel queries that do not benefit from it. It is available in SQL Server 2022 and later, needs compatibility level 160 or higher, and needs Query Store in read-write mode. In 2022, check that the DOP_FEEDBACK database scoped configuration is on for the database.

Raise the compatibility level on a copy of the database first, compare plans, and force the old plan where a regression appears. Check the Microsoft documentation for the exact compatibility level that matches your SQL Server version before you change it.

Read Execution Plans

1. Estimated vs actual rows: Large gaps usually mean stale statistics or a poor cardinality estimate.
2. Spills to tempdb: A sort or hash warning means the memory grant was too small.
3. Key lookups: Many lookups suggest the index needs an INCLUDE column.
4. Implicit conversions: A parameter type that differs from the column type (e.g. nvarchar against varchar) can block an index seek.

Transactions, Isolation Levels and Optimized Locking

Keep transactions short, touch tables in the same order everywhere, and use row versioning (Read Committed Snapshot Isolation, or RCSI) for read-heavy OLTP so readers don’t block writers. These habits are part of SQL Server performance tuning best practices because blocking often looks like a slow query.

Isolation Levels Compared

RCSI Trade-offs

RCSI makes a SELECT read the last committed version of a row instead of waiting for a lock. The cost is extra version storage, normally in tempdb. With Accelerated Database Recovery (ADR), the version store lives in the user database (the persistent version store, PVS).

Behaviour also changes. Code that relied on a blocking read to wait for a writer, such as a “read then update” pattern, now sees the old value. Test this in a copy of the database first.

Optimized Locking in SQL Server 2025

SQL Server 2025 adds optimized locking, which uses transaction ID (TID) locking and lock after qualification (LAQ). A TID lock replaces many row locks, and LAQ takes locks only on the rows that match the predicate. This reduces blocking and lock memory use, avoids lock escalation, and needs no application code change. It is a good reason to test 2025 with write-heavy workloads.

Optimized locking is not on by default for every database. It requires Accelerated Database Recovery (ADR) to be enabled on the database, so turn on ADR first and check the result in sys.databases. Confirm the exact database-level setting for optimized locking in the Microsoft documentation for your build.

T-SQL

-- Prerequisite for optimized locking: ADR on the database.
-- Test first and run in a quiet window.
ALTER DATABASE BankDb SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

SELECT name, is_accelerated_database_recovery_on
FROM sys.databases
WHERE name = N'BankDb';

This enables ADR and confirms it with a check of is_accelerated_database_recovery_on.

RCSI and optimized locking address different parts of the blocking problem, so measure them with and without RCSI on your own workload instead of assuming the combination is better. The animated diagram below compares classic locking with optimized locking plus RCSI for two sessions on the same table.

Deadlocks and Retries

When SQL Server picks your session as a deadlock victim, it returns error 1205. Retry in application code with a bounded count (e.g. three attempts) and a short backoff. To see the cause, read the deadlock graph from the system_health Extended Events session.

Finance Transfer Example

Move money in one short transaction. Validate the inputs first, then update the two accounts with two separate statements, lowest ID first. Because every transfer takes the locks in the same order, two opposite transfers (A to B and B to A) can’t deadlock on these two rows.

The balance check sits inside the debit UPDATE‘s WHERE clause. The row is locked when the check runs, so it sees the current balance. A separate SELECT before the update could read an older row version under RCSI.

T-SQL

-- Enable RCSI (rolls back open transactions, so run in a quiet window)
ALTER DATABASE BankDb SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
GO

CREATE OR ALTER PROCEDURE dbo.TransferFunds
    @FromId int, @ToId int, @Amount decimal(19,4)
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;

    -- Validate inputs before opening a transaction
    IF @Amount IS NULL OR @Amount <= 0
        THROW 50001, 'Amount must be greater than zero.', 1;
    IF @FromId IS NULL OR @ToId IS NULL OR @FromId = @ToId
        THROW 50002, 'Source and target accounts must be different.', 1;

    -- Work out the lock order: lowest AccountId first
    DECLARE @LowId  int = CASE WHEN @FromId < @ToId THEN @FromId ELSE @ToId END;
    DECLARE @HighId int = CASE WHEN @FromId < @ToId THEN @ToId ELSE @FromId END;

    -- Signed change for each account: negative for the debit, positive for the credit
    DECLARE @LowDelta  decimal(19,4) = CASE WHEN @LowId  = @FromId THEN -@Amount ELSE @Amount END;
    DECLARE @HighDelta decimal(19,4) = CASE WHEN @HighId = @FromId THEN -@Amount ELSE @Amount END;

    BEGIN TRY
        BEGIN TRANSACTION;

        UPDATE dbo.Accounts
           SET Balance = Balance + @LowDelta
         WHERE AccountId = @LowId
           AND (@LowDelta > 0 OR Balance >= @Amount);
        IF @@ROWCOUNT = 0
            THROW 50003, 'Account not found or insufficient funds.', 1;

        UPDATE dbo.Accounts
           SET Balance = Balance + @HighDelta
         WHERE AccountId = @HighId
           AND (@HighDelta > 0 OR Balance >= @Amount);
        IF @@ROWCOUNT = 0
            THROW 50003, 'Account not found or insufficient funds.', 1;

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
        THROW;
    END CATCH
END;

The procedure rejects zero, negative and NULL amounts, and it rejects a transfer from an account to itself. If either update finds no row to change, the transaction rolls back, so a failed debit never leaves a half-finished credit behind. XACT_ABORT ON also rolls back the whole transaction on any runtime error.

The fixed order only protects code that follows it. Any other procedure that updates the same accounts in a different order, or a trigger that touches other rows, can still deadlock with this one. Keep the retry logic for error 1205 in place.

Connection Management and Microsoft.Data.SqlClient Best Practices

Use Microsoft.Data.SqlClient (v7.0.1 is shown in the current API docs) and keep the defaults Encrypt=Mandatory and TrustServerCertificate=false. When an app starts failing with certificate errors after a driver upgrade, the driver is not broken. The client simply does not trust the server certificate. Fix the certificate chain or the host name instead of switching on TrustServerCertificate. This is one of the most useful SQL Server best practices for developers.

The animated diagram below shows how the client decides whether a connection succeeds and which fix to choose.

Encrypt Options Compared

Encrypt=Strict uses TDS 8.0 and cannot be bypassed with TrustServerCertificate. Use it when your server supports TDS 8.0. Avoid TrustServerCertificate=true in production, because it skips the server identity check.

Connection Pooling Rules

• Open late, close early: Use using or await using so the connection returns to the pool even when an exception occurs.
• One connection per thread: A SqlConnection is not thread-safe, so never share it.
• Keep connection strings identical: Each distinct string creates its own pool. Per-request values (e.g. a user name in the string) fragment the pool.
• Watch Max Pool Size: The default is 100. Pool exhaustion shows up as “timeout period elapsed prior to obtaining a connection from the pool”. The usual cause is a leaked connection, so look for missing disposal before raising the limit.

Availability Groups and Read-Only Routing

Connect to the availability group listener name, never a node name. Add MultiSubnetFailover=True when the listener spans subnets, so the client tries all IP addresses in parallel. Add ApplicationIntent=ReadOnly for reporting workloads that should use read-only routing.

C# Example: Strict Encryption and a Typed Parameter

Example: a retail app looks up orders for one customer. The parameter has an explicit type and size, which avoids implicit conversions and plan cache bloat.

C# (.NET)

using System.Data;
using Microsoft.Data.SqlClient;

var builder = new SqlConnectionStringBuilder
{
    DataSource = "orders-listener.contoso.com",
    InitialCatalog = "Sales",
    IntegratedSecurity = true,
    Encrypt = SqlConnectionEncryptOption.Strict,
    MultiSubnetFailover = true,
    ApplicationIntent = ApplicationIntent.ReadWrite,
    MaxPoolSize = 100
};

await using var connection = new SqlConnection(builder.ConnectionString);
await connection.OpenAsync();

await using var command = new SqlCommand(
    "SELECT OrderId, OrderDate FROM dbo.Orders WHERE CustomerRef = @CustomerRef;",
    connection);
command.Parameters.Add("@CustomerRef", SqlDbType.VarChar, 20).Value = "C-10045";

await using var reader = await command.ExecuteReaderAsync();
while (await reader.ReadAsync())
{
    Console.WriteLine($"{reader.GetInt32(0)} {reader.GetDateTime(1):d}");
}

This opens a strict, encrypted connection and returns it to the pool when the block ends.

For transient errors, the driver offers configurable retry logic (SqlRetryLogicOptions with SqlConfigurableRetryFactory). Assign a provider to the connection or command, and keep the retry count and delay bounded.

Python Equivalent with pyodbc

Use the ODBC Driver for SQL Server, set Encrypt=yes and TrustServerCertificate=no, and pass values through ? placeholders. Match the driver name to the one installed on your machine.

Python

import os
import pyodbc

conn_str = (
    "DRIVER={ODBC Driver 18 for SQL Server};"
    "SERVER=orders-listener.contoso.com;"
    "DATABASE=Sales;"
    f"UID={os.environ['SQL_USER']};PWD={os.environ['SQL_PASSWORD']};"
    "Encrypt=yes;TrustServerCertificate=no;"
    "MultiSubnetFailover=Yes;"
)

with pyodbc.connect(conn_str) as conn:
    cursor = conn.cursor()
    cursor.execute(
        "SELECT OrderId, OrderDate FROM dbo.Orders WHERE CustomerRef = ?",
        "C-10045",
    )
    for row in cursor.fetchall():
        print(row.OrderId, row.OrderDate)

This keeps the password out of the source code and sends the value as a parameter, not as part of the SQL text.

SQL Server Security Best Practices: Least Privilege, Injection and Encryption

Use Windows or Microsoft Entra authentication, give each application its own login with only the permissions it needs, and never connect an application as sa or as a member of db_owner. These SQL Server security best practices limit the damage if one credential or one query is compromised.

Apply the Least Privilege Pattern

Create a database role for the application, grant it EXECUTE on a schema, and give it no direct table access. Stored procedures and tables owned by the same principal use ownership chaining, so the procedure can read the tables even though the caller cannot.

T-SQL

CREATE LOGIN [CORP\svc-orders-app] FROM WINDOWS;
GO
USE OrdersDb;
GO
CREATE SCHEMA app AUTHORIZATION dbo;
GO
CREATE USER [CORP\svc-orders-app] FOR LOGIN [CORP\svc-orders-app];
CREATE ROLE app_orders_role;
GRANT EXECUTE ON SCHEMA::app TO app_orders_role;
ALTER ROLE app_orders_role ADD MEMBER [CORP\svc-orders-app];

This creates the login, the user, and a role that can only run procedures in the app schema.

Prevent SQL Injection in Dynamic SQL

Build dynamic SQL with parameters through sp_executesql and never concatenate user input into the query text. Microsoft guidance also says to review every piece of code that calls EXEC, EXECUTE or sp_executesql. Dynamic SQL also breaks ownership chaining, so the caller needs permissions on the underlying tables.

T-SQL

DECLARE @sql nvarchar(max) =
    N'SELECT OrderId, OrderDate, Total
      FROM dbo.Orders
      WHERE CustomerId = @CustomerId AND OrderDate >= @From;';

EXEC sys.sp_executesql
     @sql,
     N'@CustomerId int, @From date',
     @CustomerId = 42,
     @From = '2026-01-01';

-- Object names cannot be parameters, so quote them
DECLARE @table sysname = N'Orders';
SET @sql = N'SELECT COUNT(*) FROM dbo.' + QUOTENAME(@table) + N';';
EXEC sys.sp_executesql @sql;

Typed parameters also give you plan reuse. QUOTENAME is for object names only, and you should still check them against an allow-list.

Encrypt Data in Transit, at Rest and in Columns

• In transit: Use TLS with a valid server certificate. See the connection management section for Encrypt settings.
• At rest: Enable Transparent Data Encryption (TDE) to protect data files and backups from a stolen disk or file copy. TDE does not protect against a user who has permission to query the data.
• Sensitive columns: Use Always Encrypted when even DBAs should not read the values. The keys stay with the client.
• Backups: Encrypt them, and store the certificate or key separately. Without it, the backup cannot be restored.

Audit Activity and Reduce the Attack Surface

Use SQL Server Audit to write to a file or the Windows event log. Capture logins, permission changes and access to sensitive tables. Disable or rename sa if you don’t need it, and keep xp_cmdshell and other unused features turned off. This is a core item on any SQL Server DBA checklist.

Example: Patient Data in a Healthcare System

Give the reporting team a read-only role with column-level permissions, so identifying columns stay out of reach.

T-SQL

CREATE ROLE reporting_role;
GRANT SELECT ON dbo.Patient (PatientId, AdmissionDate, WardCode) TO reporting_role;
DENY  SELECT ON dbo.Patient (FullName, NationalId) TO reporting_role;

Dynamic data masking can hide values in query results, but it is a convenience and not a security boundary. A user who can filter or infer values can still work around it, so rely on permissions and encryption.

SQL Server Backup Best Practices, High Availability and Restore Testing

A backup is only proven when you have restored it. Match the recovery model to your recovery point objective (RPO, the amount of data loss you can accept), take full, differential and log backups, keep copies off the server, and test restores on a schedule. These are the core SQL Server backup best practices.

Choose a Backup Strategy That Matches Your RPO and RTO

The recovery model decides which backups are possible. RTO means recovery time objective, the time you can afford to be down.

In FULL recovery, SQL Server keeps log records until a log backup has captured them. With no log backups, the log cannot be reused, so it grows until the disk is full. Switch to SIMPLE if you do not need point-in-time recovery.

Example: a retail orders database takes a full backup nightly, a differential every four hours and a log backup every 10 minutes. That gives an example RPO of about 10 minutes. It is an illustration, not a recommendation, so set your own interval from business needs.

Use CHECKSUM, Compression and Encryption on Every Backup

CHECKSUM detects page corruption while the backup runs. Compression reduces size and I/O. Encryption protects the file once it leaves the server.

RESTORE VERIFYONLY is the minimum check. It confirms the backup is readable, but it does not prove the data is consistent. Only a real restore followed by DBCC CHECKDB on the restored copy does that.

ZSTD Compression and Secondary Backups in SQL Server 2025

ZSTD backup compression is GA in SQL Server 2025 but is not the default. Enable it per backup with COMPRESSION (ALGORITHM = ZSTD, LEVEL = LOW | MEDIUM | HIGH), or instance-wide by setting backup compression algorithm to 3 with sp_configure. Test CPU cost and backup time first, because HIGH can take much longer.

Full, differential and log backups can now run on availability group secondary replicas (GA), which takes load off the primary. Backups to immutable storage are also GA, which helps against ransomware.

The animated diagram below shows the full path from backup to a verified restore.

High Availability Is Not a Backup

An availability group replicates a bad DELETE or corruption to the secondary just as quickly. Use HA for uptime and backups for recovery.

Protect Copies, Credentials and Keys

Keep one copy on a local share for fast restores and one offsite or on immutable storage. Document the backup credential, certificate and private key, and store them separately from the backups. If you lose the certificate, encrypted backups cannot be read.

Backup and Restore Test Script

The script below backs up, restores to a test name with MOVE, and checks consistency. The test server needs the same certificate. Run RESTORE FILELISTONLY first to get the logical file names.

SQL (T-SQL)

-- Optional: make ZSTD the instance default (SQL Server 2025)
EXEC sp_configure 'backup compression algorithm', 3;
RECONFIGURE;

BACKUP DATABASE SalesDB
TO DISK = N'D:\Backup\SalesDB_full.bak'
WITH CHECKSUM,
     COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM),
     ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert),
     STATS = 10;

BACKUP LOG SalesDB
TO DISK = N'D:\Backup\SalesDB_log.trn'
WITH CHECKSUM,
     COMPRESSION (ALGORITHM = ZSTD, LEVEL = LOW),
     ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

-- On the restore test server
RESTORE FILELISTONLY FROM DISK = N'D:\Backup\SalesDB_full.bak';

RESTORE DATABASE SalesDB_RestoreTest
FROM DISK = N'D:\Backup\SalesDB_full.bak'
WITH MOVE N'SalesDB'     TO N'E:\RestoreTest\SalesDB_RestoreTest.mdf',
     MOVE N'SalesDB_log' TO N'F:\RestoreTest\SalesDB_RestoreTest.ldf',
     CHECKSUM, RECOVERY, STATS = 10;

DBCC CHECKDB (SalesDB_RestoreTest) WITH NO_INFOMSGS, ALL_ERRORMSGS;

This restores the full backup under a new name and reports any corruption. Record how long the restore took, because that is your measured RTO.

For a point-in-time restore, restore the full backup (and the latest differential) with NORECOVERY. Then restore each log backup, and add STOPAT = '2026-10-13T09:55:00' to the last one with RECOVERY. This needs FULL recovery and an unbroken log chain.

Monitoring SQL Server: Wait Stats, Extended Events and Performance Counters

Start with wait statistics to see what the instance is waiting on. Then use Query Store and Extended Events to find the queries and events behind those waits. This order is the core of SQL Server performance tuning best practices, because it stops you from guessing.

Common Wait Types and What They Point To

A wait type is the reason a request had to pause. Treat it as a pointer, not a diagnosis. Confirm it with a query, a plan or a counter before you change anything.

T-SQL

SELECT TOP (10)
       wait_type,
       waiting_tasks_count,
       wait_time_ms,
       signal_wait_time_ms,
       CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER () AS decimal(5,2)) AS pct_of_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0
  AND wait_type NOT IN (N'SLEEP_TASK', N'LAZYWRITER_SLEEP', N'XE_TIMER_EVENT',
      N'XE_DISPATCHER_WAIT', N'REQUEST_FOR_DEADLOCK_SEARCH', N'CHECKPOINT_QUEUE',
      N'DIRTY_PAGE_POLL', N'LOGMGR_QUEUE', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
      N'SP_SERVER_DIAGNOSTICS_SLEEP', N'BROKER_TO_FLUSH', N'BROKER_TASK_STOP',
      N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP', N'QDS_ASYNC_QUEUE', N'WAITFOR')
ORDER BY wait_time_ms DESC;

This returns the top waits since the last restart, minus a partial list of idle waits. Take two snapshots and compare them to see current behaviour.

Use Extended Events, Not Profiler

Extended Events is the lightweight tracing system, and SQL Trace and Profiler are deprecated. Keep the built-in system_health session running for deadlock graphs. Add a small session for slow statements.

T-SQL

CREATE EVENT SESSION [LongRunningStatements] ON SERVER
ADD EVENT sqlserver.sql_statement_completed
(
    ACTION (sqlserver.database_name, sqlserver.client_app_name, sqlserver.sql_text)
    WHERE duration > 1000000   -- microseconds, so 1 second
)
ADD TARGET package0.event_file
(
    SET filename = N'LongRunningStatements.xel', max_file_size = 50, max_rollover_files = 4
)
WITH (MAX_DISPATCH_LATENCY = 30 SECONDS, STARTUP_STATE = ON);

ALTER EVENT SESSION [LongRunningStatements] ON SERVER STATE = START;

The file target rolls over at a fixed size, so the session cannot fill the disk.

Counters and Alerts Worth Setting Up

• Page life expectancy: Watch the trend against your own baseline. A fixed number such as 300 does not fit every server.
• Batch requests per second: Use it to read load changes next to waits.
• Log file percent used: Alert before the log fills the volume.
• Free space: Check data, log and tempdb volumes separately.
• AG synchronization lag: Alert when secondaries fall behind.
• Errors and jobs: Alert on severity 17 to 25 errors and on job failures.

For backups, alert on the age of the last successful backup, not on whether the job ran. A job can finish without producing a usable backup. This also belongs on any SQL Server DBA checklist.

Patching and Upgrading to SQL Server 2025: What to Check First

Patch on a regular cadence, test the upgrade on a copy that has the same linked servers, certificates and jobs, and plan the outage window before you start. Most upgrade surprises come from things outside the database files.

Version, Support and Current Builds

A CU (cumulative update) carries fixes and features. A GDR (General Distribution Release) carries security-only fixes for servers that don’t apply CUs. Each instance sits on one of two tracks, and the rule is one-way.

1. GDR track: the instance has only had GDR updates and receives security fixes only (e.g., 17.0.1135.8 for SQL Server 2025).
2. CU track: the instance has had at least one CU. From here, security-only fixes arrive as a CU+GDR package built on the CU you already have (e.g., CU8+GDR 17.0.4085.5).
3. Moving from GDR to CU is allowed. Install a CU and the instance joins the CU track.
4. Moving from CU back to GDR is not allowed. Once a CU is installed, only CU and CU+GDR packages apply.

Decide the track before the first patch. If you may want bug fixes or features later, plan to move to the CU track once and stay there. If you only want security fixes, stay on GDR until you are ready to commit to CUs.

T-SQL

SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion,
       SERVERPROPERTY('ProductLevel')   AS ProductLevel,
       SERVERPROPERTY('Edition')        AS Edition;

Compare the returned build number with the table above to see which track and update level the instance is on.

Is the Upgrade Worth It?

Yes for write-heavy or backup-heavy systems, after testing. The practical 2025 gains are:

• Optimized locking, which uses transaction ID (TID) locking and lock after qualification (LAQ) to reduce blocking and lock memory, and to avoid lock escalation, with no application code changes.
• Query Store on readable secondaries, on by default (in 2022 it was off by default and needed trace flag 12606).
• ZSTD backup compression and backups on AG secondaries.
• Resource Governor and higher limits in Standard edition.
• tempdb space governance.

The trade-off is testing effort. DiskANN vector indexes are preview only, so keep them out of production.

What Breaks: Linked Servers and TLS

A DBA report found that linked servers using SQLNCLI or MSOLEDBSQL can fail after an in-place upgrade to 2025, because of stricter TLS certificate validation. Setup can also restart the service up to three times, so the outage is longer than one restart. Fix the certificates or the provider settings before cutover, then test every linked server afterwards.

T-SQL

DECLARE @name sysname;
DECLARE ls CURSOR FAST_FORWARD FOR
    SELECT name FROM sys.servers WHERE is_linked = 1;
OPEN ls;
FETCH NEXT FROM ls INTO @name;
WHILE @@FETCH_STATUS = 0
BEGIN
    BEGIN TRY
        EXEC sp_testlinkedserver @name;
        PRINT @name + ': OK';
    END TRY
    BEGIN CATCH
        PRINT @name + ': FAILED - ' + ERROR_MESSAGE();
    END CATCH;
    FETCH NEXT FROM ls INTO @name;
END;
CLOSE ls;
DEALLOCATE ls;

The animated diagram below shows the safe order of steps, including the retry loop for failed linked server tests.

In-Place vs Side-by-Side Migration

Use side-by-side for critical systems. Use in-place only for small or non-critical instances where a longer window is acceptable.

After the Upgrade: Compatibility Level

Keep the old compatibility level until the application is tested. Let Query Store capture baseline plans, then raise the level and force back any plan that regressed.

The level used below, 170 for SQL Server 2025, is not in the verified research for this article. Confirm it in the Microsoft documentation article “ALTER DATABASE compatibility level (Transact-SQL)” before you run the statement, and use the highest level that article lists for your version.

T-SQL

-- Check the current level
SELECT name, compatibility_level FROM sys.databases WHERE name = N'SalesDb';

-- Raise it after testing. Replace 170 if the Microsoft docs list a different
-- level for your SQL Server 2025 build.
ALTER DATABASE SalesDb SET COMPATIBILITY_LEVEL = 170;

Common Anti-Patterns and SQL Server DBA Production Readiness Checklist

Most production incidents trace back to a small set of repeated mistakes. Use the table below to spot them, then run the checklist before a server goes live.

Common SQL Server Anti-Patterns

SQL Server Production Readiness Checklist

This SQL Server DBA checklist combines the configuration, security and backup rules from the sections above. Work through it in order.

1. Confirm the version and patch level, and choose the CU or GDR track on purpose.
2. Set the SQL Server max server memory setting to a specific value, with min server memory at 0.
3. Set MAXDOP and cost threshold for parallelism from the NUMA rule and measured plan costs.
4. Lay out tempdb with equally sized, pre-sized files on fast storage.
5. Separate data, log and tempdb volumes where the storage design allows.
6. Enable instant file initialization for data files.
7. Enable Query Store on user databases with a sensible size and capture mode.
8. Choose the isolation level deliberately, and test RCSI before turning it on.
9. Set connection strings with Encrypt, the listener name and MultiSubnetFailover=True where it applies.
10. Create least-privilege roles for each application, and disable or rename sa.
11. Enforce TLS in transit and enable TDE at rest.
12. Turn on SQL Server Audit for logins, permission changes and sensitive tables.
13. Schedule full, differential and log backups with CHECKSUM, compression and encryption.
14. Keep an offsite or immutable copy, and document backup keys and certificates.
15. Restore on a schedule and run DBCC CHECKDB on the restored copy.
16. Alert on wait trends, failed jobs, severity 17-25 errors and the age of the last good backup.
17. Write the upgrade plan, including linked server tests and the outage window.

These items also form a short SQL Server security best practices review (items 10 to 12) and a SQL Server backup best practices review (items 13 to 15).

Key takeaways

• Cap max server memory: Start from about 75% of the memory that is available to SQL Server (after other processes and other instances), keep min server memory at 0, and always use a specific value if Lock Pages in Memory is granted.
• Tune MAXDOP and cost threshold by measurement: Begin with the Microsoft NUMA-based MAXDOP guidance, use database-scoped MAXDOP or Resource Governor for exceptions, and raise cost threshold for parallelism above the default of 5 after checking CXPACKET/CXCONSUMER waits.
• Use Strict or Mandatory encryption with a valid certificate: Fix the certificate chain or host name when connections fail after a driver upgrade. Avoid TrustServerCertificate=true in production.
• Give applications least privilege: Use a dedicated login and a role with EXECUTE on a schema, never sa or db_owner, and pass every value through typed parameters.
• Enable Query Store: Turn it on for every database you care about, so you can find regressions, force a known good plan, and keep baseline plans before a compatibility level change.
• Test restores, not just backups: Take backups with CHECKSUM, keep an offsite or immutable copy, and restore to a test name regularly, then run DBCC CHECKDB on the restored copy.
• Test the SQL Server 2025 upgrade on a copy first: Include linked servers, certificates and jobs, and run sp_testlinkedserver afterwards because stricter TLS validation can break them. Evaluate optimized locking with RCSI for write-heavy workloads, and keep DiskANN vector indexes out of production while they are preview only.

That’s all! Happy coding!

Did this guide help you to set up and tune SQL Server for production? Please share your questions or experience in the comments below.

Bookmark this page for your next production review and share it with your team. Subscribe to TheCodeBuzz to get new database best-practice guides in your inbox.

FAQ

What should I set max server memory to in SQL Server?

Start with about 75% of the memory that is available to the instance, meaning the total minus what the OS, other instances and other processes use, and leave min server memory at 0. The default is about 2 TB, which is effectively unlimited, so you should cap it on every version. If Lock Pages in Memory is granted to the service account, you must set a specific value, not the default. Set it with sp_configure 'max server memory (MB)' followed by RECONFIGURE, and check the result in sys.configurations.

What is the best MAXDOP and cost threshold for parallelism setting?

There is no single best value. Start from Microsoft’s NUMA-based MAXDOP guidance, set it per database with ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP for mixed workloads, and use Resource Governor workload groups where one workload needs a different limit. Avoid MAXDOP 1 server-wide, because it breaks parallel index builds and slows reporting queries. The cost threshold for parallelism defaults to 5, which is too low for modern hardware, so raise it based on observed plan costs and check the effect on CXPACKET and CXCONSUMER waits.

How many tempdb files should I have, and how should I size them?

Start with a small number of equally sized data files, up to the number of cores as Microsoft guidance suggests, and add more only if monitoring shows allocation contention. Pre-size the files and use a fixed growth increment, so autogrow stays an emergency measure and not a routine event. Equal sizes matter because SQL Server spreads allocations across files, and uneven files lead to uneven use. On SQL Server 2025 you can also use Resource Governor tempdb space governance, which stops a workload with an error when it exceeds its limit.

Why does my app fail to connect after upgrading Microsoft.Data.SqlClient, with certificate errors?

The driver now defaults to Encrypt=Mandatory and TrustServerCertificate=false, so it rejects a server certificate that the client does not trust. This is not a driver bug. Fix the certificate chain or make sure the host name in the connection string matches the certificate, instead of switching on TrustServerCertificate=true, which skips server identity checks. Use Encrypt=Strict where the server supports TDS 8.0, because Strict cannot be bypassed with TrustServerCertificate.

Should I enable Query Store, optimized locking or Read Committed Snapshot Isolation?

Yes to Query Store on every user database you care about, because it helps you find regressions and force a known good plan. Enable Read Committed Snapshot Isolation (RCSI) after testing, since it adds version storage and changes behavior for code that relied on blocking reads. Optimized locking comes with SQL Server 2025 and needs no application code changes. It works best together with RCSI, so it is a good reason to test 2025 for heavy write workloads.

Sources and further reading

• What’s New in SQL Server 2025 – SQL Server (Microsoft Learn)
• Latest Updates and Version History for SQL Server (Microsoft Learn)
• Server Memory Configuration Options – SQL Server (Microsoft Learn)
• Memory Management Architecture Guide – SQL Server (Microsoft Learn)
• Resource Governor – SQL Server (Microsoft Learn)
• SQL Server Security Best Practices – SQL Server (Microsoft Learn)
• Encryption and Certificate Validation in Microsoft.Data.SqlClient (Microsoft Learn)
• Whats new in the Backup/Restore area in SQL Server 2025 (Microsoft Tech Community)
• SQL Server 2025 New Features and Enhancements (MSSQLTips)
• SQL Server 2025 Backup Compression Algorithm (SQLServerCentral)

Diagrams are original illustrations created by and for TheCodeBuzz.

The post SQL Server Best Practices and Guidelines-2026 first appeared on TheCodeBuzz.

Most PostgreSQL outages and security incidents come from clusters that were never patched or never upgraded, not from exotic bugs. This guide is for engineers, architects and DBAs who run PostgreSQL in production. It is a compact reference you can bookmark and check a cluster against.

Here is where things stand in October 2026. PostgreSQL 18 is the current stable major, and 18.6, dated 2026-08-13, is its latest minor. PostgreSQL 14 receives its last fixes on 2026-11-12, so anyone still on it has a deadline measured in weeks. I cover patching and upgrades first, because that is where most production risk sits.

After that come the PostgreSQL 18 features that change how you design schemas and indexes, with the reasoning behind each rule so you can judge where it applies to your workload. These PostgreSQL best practices start with a summary table and end with a checklist and FAQ.

Version note: this guide targets PostgreSQL 18 (18.6), and also covers 17.11, 16.15, 15.19 and 14.24 for patching and upgrade planning, with PostgreSQL 19 Beta 4 mentioned only for testing.

 

PostgreSQL best practices at a glance

Minor releases contain only bug and security fixes, which is why they are low-risk to apply. Low-risk is not no-risk: read the release notes, test against your workload and schedule the restart. The CVE examples above show why you should not defer them for long.

Key order matters because a B-tree keeps neighbouring values on neighbouring pages. Time-ordered keys append to the right edge of the index, while random keys touch pages all over it, which hurts cache hit rates on large tables.

Skip scan changes the column-order trade-off but does not remove it. PostgreSQL has to probe the index once for each distinct value of the omitted leading column. With a handful of values that is cheap.

With millions of values it is not, and an index that leads with the column you actually filter on is still the better choice. Check the plan before you change any existing index.

Example: uuidv7 key, temporal constraint and a skip scan candidate

SQL

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE room_booking (
    booking_id uuid NOT NULL DEFAULT uuidv7() PRIMARY KEY,
    tenant_id  integer NOT NULL,
    room_id    integer NOT NULL,
    status     text NOT NULL,   -- few distinct values, for example 'confirmed' or 'cancelled'
    during     tstzrange NOT NULL,
    CONSTRAINT no_double_booking
        UNIQUE (room_id, during WITHOUT OVERLAPS)
);

-- Leading column has few distinct values; queries may filter on tenant_id alone.
CREATE INDEX room_booking_status_tenant_idx
    ON room_booking (status, tenant_id);

The scalar room_id in the temporal key needs btree_gist. The range column during is what the constraint checks for overlap. The index behind that constraint also starts with room_id, so lookups by room already have an index and you do not need to add another.

The (status, tenant_id) index is the skip scan candidate. The query below has an equality condition on tenant_id but none on the leading column status. Before PostgreSQL 18, this index could not serve it efficiently. Run it against representative data after an ANALYZE. On a tiny table the planner may prefer a sequential scan, so the SET LOCAL line is for testing only and shows whether the index is usable at all.

SQL

ANALYZE room_booking;

BEGIN;
SET LOCAL enable_seqscan = off;   -- test only: see whether the index can serve the query

EXPLAIN (ANALYZE, BUFFERS)
SELECT booking_id
FROM room_booking
WHERE tenant_id = 42;

ROLLBACK;

In the plan, look for a scan on room_booking_status_tenant_idx with tenant_id = 42 as the index condition, even though the query never mentions status.

PostgreSQL 18 also reports the number of index searches in EXPLAIN ANALYZE. A skip scan shows roughly one search per distinct status value.

Then rerun the query without the SET LOCAL line and compare timing and buffer counts with the plan the planner picks on its own. If the planner chooses a sequential scan or another index and is faster, keep that plan. If status has many distinct values in your data, a separate index on (tenant_id) is the better design.

Plan upgrades and the production readiness checklist

Support lifecycle

PostgreSQL ships a major version about once a year and supports each for five years. PostgreSQL 18 was first released on 2025-09-25, and its final release is due 2030-11-14. PostgreSQL 14 stops receiving fixes on 2026-11-12, so schedule that move now. Since version 10, minors increment the second number (18.5 to 18.6).

Minor releases carry only bug and security fixes, so they are low-risk to apply, but not zero-risk. Test them in staging and keep a rollback plan. Apply them promptly. Release 18.1 fixed CVE-2025-12817, where CREATE STATISTICS skipped a schema CREATE privilege check.

Release 18.4 fixed CVE-2026-6575 in pg_restore_attribute_stats along with more than 60 bugs. As of early October 2026 the newest minors are 18.6, 17.11, 16.15, 15.19 and 14.24, all dated 2026-08-13.

PostgreSQL 19 is in beta (Beta 4 was announced on 2026-09-24). Do not run it in production, but do test your own workloads against it so you find regressions early.

Upgrading with pg_upgrade

PostgreSQL 18 keeps planner statistics across the upgrade, runs checks in parallel with --jobs, and adds --swap, which swaps directories instead of copying, cloning or linking. The animated diagram below walks through this path.

Four rules govern the new cluster and the run itself:

• Compatible encoding and locale. Initialise the new cluster with an encoding and locale that match the old one. pg_upgrade refuses to proceed if they differ. Read the old values first and pass them to initdb explicitly rather than relying on the environment.
• Matching checksum settings. initdb in PostgreSQL 18 enables data checksums by default, and pg_upgrade requires both clusters to agree. If the old cluster has none, create the new one with --no-data-checksums. You can enable checksums later, offline, with pg_checksums --enable while the cluster is cleanly shut down. It rewrites every data file, so plan the window.
• Run as the postgres user. Run initdb and pg_upgrade as the operating-system user that owns the data directories, normally postgres. Running as root, or as a different user, causes permission failures or leaves files with the wrong owner.
• --swap leaves the old cluster unusable. It reuses the old cluster’s files instead of copying them, so you cannot start the old cluster afterwards. Your rollback is the backup you took before the upgrade, so confirm it restores before you begin.

SQL

-- Run on the OLD cluster: encoding and locale to reuse for initdb
SELECT datname,
       pg_encoding_to_char(encoding) AS encoding,
       datcollate,
       datctype
FROM pg_database
WHERE datname NOT IN ('template0', 'template1');

Bash/shell

# Run everything as the postgres user
sudo -iu postgres

# Does the old cluster use checksums?
pg_controldata -D /var/lib/postgresql/14/main | grep -i checksum

# New cluster: match encoding and locale from the query above.
# Add --no-data-checksums ONLY if the old cluster has no checksums.
/usr/lib/postgresql/18/bin/initdb \
  --encoding=UTF8 --locale=en_US.UTF-8 \
  --no-data-checksums \
  -D /var/lib/postgresql/18/main

# Dry run: checks only, changes nothing
/usr/lib/postgresql/18/bin/pg_upgrade --check --jobs=4 \
  -b /usr/lib/postgresql/14/bin -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/14/main -D /var/lib/postgresql/18/main

# Real run, after a verified backup. The old cluster is unusable afterwards.
/usr/lib/postgresql/18/bin/pg_upgrade --jobs=4 --swap \
  -b /usr/lib/postgresql/14/bin -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/14/main -D /var/lib/postgresql/18/main

# Optional, later, with the cluster cleanly shut down:
# pg_checksums --enable -D /var/lib/postgresql/18/main

After the upgrade

Do not reopen the application to traffic until you have checked three things.

1. Start the new cluster and confirm the version with SELECT version();.
2. Check statistics. PostgreSQL 18 carries planner statistics across, which shortens the slow period after an upgrade, but verify rather than assume. Find tables that have rows but no statistics, then run ANALYZE.
3. Run your application’s test suite and a representative query set against the new cluster. Compare the plans and timings of your slowest queries with a pre-upgrade baseline.

SQL

-- Tables that have rows but no planner statistics
SELECT c.oid::regclass AS table_name, c.reltuples::bigint AS est_rows
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'm')
  AND n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast')
  AND c.reltuples > 0
  AND NOT EXISTS (
    SELECT 1 FROM pg_stats s
    WHERE s.schemaname = n.nspname AND s.tablename = c.relname
  );

Bash/shell

# Refresh statistics in every database
vacuumdb --all --analyze-only --jobs=4

Low-downtime alternative: logical replication

If you cannot afford the downtime of pg_upgrade, build a new cluster on the target major version and keep it in sync with logical replication. Then switch applications over in a short window. PostgreSQL 17 improved logical replication for high-availability setups and major-version upgrades, so this path is better supported on recent versions. It also gives you a rollback: the old cluster stays intact until you decide to retire it.

The cost is more moving parts. Logical replication does not copy schema changes, so you must create the schema on the target and freeze DDL during the migration.

Sequence values need to be synchronised before cutover.

Tables need suitable replica identities, usually a primary key. Rehearse the whole procedure on a copy of production first.

Production readiness checklist

Each item names something you can check. If you cannot show the evidence, treat the item as not done.

1. Latest minor applied. SHOW server_version; matches the newest minor of your major (18.6, 17.11, 16.15, 15.19 or 14.24 as of this writing).
2. Supported major with a dated plan. You are not on a version past its end-of-fix date. If you run PostgreSQL 14, the upgrade must finish before 2026-11-12.
3. WAL archiving works. archive_mode = on with a working archive command or library. pg_stat_archiver shows a recent last_archived_time and a failed_count that is not growing. Alert when archiving fails, because unarchived WAL piles up on the primary’s disk.
4. A restore has been tested. You have restored a base backup plus archived WAL to a separate host, reached a chosen point in time, and run application queries against it. Record the date and how long it took, and repeat on a schedule.
5. pg_stat_statements is enabled. It is in shared_preload_libraries (this needs a restart), and CREATE EXTENSION pg_stat_statements; has been run in the database you query. A dashboard or a regular review uses it to find the slowest and most frequent statements.
6. Autovacuum is monitored. You alert on dead tuples and time since the last autovacuum for large tables, on long-running transactions and stale replication slots that hold back cleanup, and on transaction ID age (age(datfrozenxid)) approaching the freeze limits.
7. TLS is required. ssl = on with a valid certificate, and pg_hba.conf uses hostssl entries rather than plain host for network clients. Clients connect with sslmode=verify-full where possible.
8. Passwords use scram-sha-256. password_encryption = scram-sha-256, and no line in pg_hba.conf uses md5 or trust for network access. Existing md5 hashes cannot be converted, so reset those passwords after changing the setting.
9. Least-privilege roles. Applications do not connect as a superuser or as the schema owner. Check with \du and by reviewing grants.
10. Replication lag has thresholds. Derive them from your recovery point objective: one warning level and one paging level, measured on pg_stat_replication (replay_lag or byte lag) and on standbys. Alert also when a standby disconnects entirely, since a missing row looks like zero lag.
11. Failover has been exercised. You have promoted a standby on purpose and confirmed that applications reconnect.
12. Data checksums are on, or the plan is written down. New PostgreSQL 18 clusters have them by default. For older clusters, schedule an offline pg_checksums --enable.
13. Disk and connection headroom are alerted. You get a warning before the data, WAL or archive volumes fill, and before connection counts approach max_connections.

Text

# pg_hba.conf: TLS required, SCRAM only, no trust/md5 for network clients
# TYPE     DATABASE  USER  ADDRESS        METHOD
local      all       postgres              peer
hostssl    all       all   10.0.0.0/16    scram-sha-256
hostnossl  all       all   0.0.0.0/0      reject

SQL

-- WAL archiving: failures should be zero and last_archived_time recent
SELECT archived_count, failed_count, last_archived_time, last_failed_time
FROM pg_stat_archiver;

-- Replication lag per standby (run on the primary)
SELECT application_name, state, replay_lag,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;

-- Autovacuum: tables with the most dead tuples
SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;

-- Transaction ID age per database
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;

-- Auth and TLS settings
SHOW password_encryption;
SHOW ssl;

Key takeaways

• Patch minors promptly. Run the latest minor of your major version. Minors carry only bug and security fixes, so they are low-risk, but still roll them out through staging first.
• Retire PostgreSQL 14 now. Set an upgrade date before its final fixes arrive in November 2026, and prefer PostgreSQL 18 as the target.
• Use uuidv7() for UUID primary keys. Timestamp-ordered values keep inserts localized in the index.
• Recheck composite index column order. Skip scan in PostgreSQL 18 may make some indexes redundant, so confirm with query plans.
• Enforce integrity in the database. Use temporal constraints instead of application-side overlap checks, and keep data checksums enabled.
• Rehearse pg_upgrade. Run pg_upgrade --check first and take a backup before using --swap.
• Prefer OAuth over shared static passwords, and benchmark io_method yourself. Inspect pg_aios on your own storage before changing the default.
• Keep PostgreSQL 19 beta out of production. Use it in test environments to try your own workloads.

FAQ

Should I upgrade to PostgreSQL 18 or 17?

Choose 18 unless something concrete blocks it, such as an extension, driver or managed service that does not support it yet. PostgreSQL 18 was first released on 2025-09-25 and is scheduled for final fixes on 2030-11-14, so it gives you the longest support window. Upgrading to 17 means you will have to run another major upgrade sooner.

PostgreSQL 18 also makes the upgrade itself easier:

• Planner statistics carry over, so the new cluster reaches normal performance sooner.
• pg_upgrade runs its checks in parallel with --jobs.
• The new --swap flag swaps directories instead of copying, cloning or linking files, which helps most when a database has many objects.

PostgreSQL 17 is a reasonable stop if your dependencies force it. It reworked vacuum memory management, improved high-concurrency workloads and bulk loading, and improved logical replication for high availability and major upgrades. Do not pick 16 or 15 as a target for a new upgrade. They have less support time left and you would repeat the work soon.

Either way, restore a production backup into a staging cluster, run pg_upgrade there, and replay your real workload before you commit. If you are still on 14, its last fixes are due on 2026-11-12, so schedule this now.

Can I enable data checksums on an existing cluster?

Yes, but not online. initdb in PostgreSQL 18 enables checksums by default, which does nothing for clusters that already exist. First check your current state:

SQL

SHOW data_checksums;

If it returns off, the usual route is the pg_checksums tool. It requires a cleanly shut-down cluster and rewrites every data file to add checksums, so downtime grows with database size. Run it on a restored copy first to measure that time. If you cannot afford the downtime, build a new cluster with checksums enabled and move the data over with logical replication.

The setting matters for major upgrades because pg_upgrade requires the old and new clusters to match. If your old cluster has no checksums and you do not want to change that during the upgrade, initialize the new 18 cluster without them:

Bash

initdb --no-data-checksums -D /var/lib/postgresql/18/main
pg_upgrade \
  --old-bindir=/usr/lib/postgresql/16/bin \
  --new-bindir=/usr/lib/postgresql/18/bin \
  --old-datadir=/var/lib/postgresql/16/main \
  --new-datadir=/var/lib/postgresql/18/main \
  --jobs=4 --check

Dropping --check runs the real upgrade. I recommend treating the upgrade and the checksum change as two separate maintenance steps. If something goes wrong, you then know which change caused it. The trade-off is that checksums add a small CPU cost, but they let PostgreSQL detect storage-level corruption instead of silently reading bad pages.

Should I use uuidv7() on existing tables?

Use it as the default for new rows and leave existing keys alone. uuidv7() is new in PostgreSQL 18 and generates timestamp-ordered UUIDs. New values are inserted near the end of a primary key index, which suits indexes and caching better than random UUIDs. Changing the default does not rewrite or invalidate existing rows, because both kinds of value are ordinary uuid values:

SQL

ALTER TABLE orders
  ALTER COLUMN id SET DEFAULT uuidv7();

Do not rewrite existing primary keys just to get ordering. That would mean updating every foreign key and external reference, and the benefit applies only to new inserts. Two caveats apply:

• A UUIDv7 embeds its creation time, so do not use it where exposing creation time to clients is a problem.
• The function does not exist before PostgreSQL 18. If any replica or application environment still runs an older major, applying the default there will fail.

Apply the change after every node runs 18. uuidv4() is also new in 18 as an alias for gen_random_uuid(), if you want a name that states the version.

Do multicolumn indexes need to be redesigned for PostgreSQL 18?

Not immediately. PostgreSQL 18 adds skip scan on multicolumn B-tree indexes, so a query that omits an equality condition on one or more leading columns can still use the index. That can make some single-purpose indexes redundant, and it relaxes how strictly you must order columns in new composite indexes.

Do not drop indexes on this basis alone. Compare the plans and timings of your real queries after the upgrade, and only then retire an index you can show is unused or covered. Dropping an index in a hurry is harder to undo than keeping it.

Is it safe to apply PostgreSQL minor releases without a long test cycle?

Minor releases carry only bug and security fixes, which makes them low-risk, but not risk-free. Skipping them has a real cost: 18.1 fixed CVE-2025-12817, where CREATE STATISTICS skipped a schema CREATE privilege check, and 18.4 fixed CVE-2026-6575 in pg_restore_attribute_stats along with over 60 bugs.

Roll the update through staging first and confirm you have a backup you have actually restored. Then move production to the latest minor of your major: 18.6, 17.11, 16.15, 15.19 or 14.24. Since version 10, minor releases change the second number (for example 10.0 to 10.1), so 18.5 to 18.6 is a minor update.

Should I test PostgreSQL 19 now?

Yes, run your own workload against it in a non-production environment. Beta 4 was announced on 2026-09-24, and the project encourages this kind of testing, so problems can be reported before the final release. Do not run a beta in production. For production, use PostgreSQL 18.

Sources and further reading

• PostgreSQL: The world’s most advanced open source database (PostgreSQL Global Development Group)
• PostgreSQL: Versioning Policy (PostgreSQL Global Development Group)
• PostgreSQL: PostgreSQL 18 Released! (PostgreSQL Global Development Group)
• PostgreSQL 18.0 Release Notes (PostgreSQL Global Development Group)

Please share this article with your friends and Subscribe to the blog to get a notification on freshly published best practices of software development.

The post PostgreSQL – Best Practices for Production first appeared on TheCodeBuzz.

Today in this article, we will go over Data Modelling – Fundamentals and Building Blocks and their usage guidelines.

What is Data Modelling

Data modeling is an important technique for effective database design, understanding the data requirements of a particular use case, and offering a structured method for understanding, representing, and implementing data structures for a given requirement.

Data Modelling normally occurs at the beginning of the development process to understand and document business requirements before database implementation.

This means it heavily helps you identify and documentation of business logic, rules, and relationships to ensure that the data model aligns with business objectives.

Data modeling focuses on organizing data at a Conceptual or Abstract or Physical level.

It aims to understand the information requirements of a business or system and define the relationships between different data entities.

Data modeling utilizes techniques like Entity-Relationship Diagrams (ERD) to represent entities, attributes, and relationships between entities, but this evolution and brainstorming does help you define your requirements in a true sense.

Along with facilitating discussions, it ensures changes to the design are visited during the early stages of development. In the world of development, which fully relies on design in the first place this does help in a greater way.

Data Modelling encourages communication between various stakeholders including the product owner, scrum, developers, or architects by providing a visual representation of data concepts that is accessible to both technical and non-technical audiences.

It very good technique for extending logical and physical design, normalization, relationship mapping, and performance optimization at the very beginning of use case or requirements explorations.

SQL and NO SQL – Data modeling is still a valid technique

Data Modelling operates at a more elevated level of abstraction, stressing entities, attributes, and relationships without getting into specific database implementation details, and hence this technique’s value holds for SQL or No SQL database design.

The outcomes of Data modeling ensure conceptualization, understanding, and representation of data requirements to various stake stakeholders and hence build confidence in the product which is going to evolve later stage as deliverables.

Type of Data Modeling Concepts

Conceptual Data Modeling

• Focuses on the high-level representation of the domain entities, business concepts, and relationships within a system.

• Helps in getting all the the fundamental entities, attributes, and relationships between.

• Provide a clear and abstract view of the business requirements, serving as a foundation for further development.

Logical Data Modeling

• This modeling helps translate the conceptual data model into a more detailed and structured format that can be implemented in a database.

• Defines tables, columns, fields, data types, relationships, and constraints for the given database management system.

• It acts as a bridge between the conceptual model and the physical implementation, ensuring a comprehensive and consistent representation of data.

Physical Data Modeling:

• Focuses on the actual implementation of the database on a specific database management system SQL or No SQL.

• Includes details such as storage structures, indexing, partitioning, and other optimization techniques to enhance performance.

• Involves decisions about how data is stored, accessed, and retrieved at the physical level, considering the specific features and requirements of the chosen DBMS.

Building blocks of Data modeling

Entities in Data Modelling

The best way to judge an entity is as some type of “real-world subject.”

At the end entity represents ” a collection of attributes or fields.”

Entities represent distinct objects, concepts, or things within a system that are described and stored as data.

These entities encapsulate relevant information through attributes, defining the properties or characteristics associated with them.

For example, in a customer relationship system, a “Customer” entity might include attributes such as “CustomerID,” “Name,” and “Email.”

Identifying and modeling entities is foundational for a clear understanding of the information requirements and relationships within a given domain or system.

Attributes in Data Modelling

Attributes provide granularity to the data model, offering a way to distinguish and categorize information within entities.

By defining these attributes, data modeling achieves a more comprehensive representation of the underlying data, enabling the organization and retrieval of specific details associated with each entity in a structured and meaningful manner.

Characteristics or properties of entities that describe the data associated with them.

Attributes provide details about the entities and are often represented as adjectives, like “Name” or “DateOfBirth.”

Relationships in Data modeling

In data modeling, relationships establish connections between entities, defining how they interact. T

These connections convey associations and dependencies, crucial for understanding the dynamics within a system.

For instance, in a database for a library, a “Customer” entity may have a relationship with an “Order” entity, indicating the association between individuals requesting an order.

• Relationships specify the cardinality and nature of connections, such as one-to-one or many-to-many, providing a structured framework for data representation.

• By modeling relationships, data modeling ensures a comprehensive understanding of how entities relate to one another, fostering accurate and efficient retrieval of information from the database.

Keys in Data modeling

• Keys play a pivotal role in data modeling by uniquely identifying and organizing data within a database.

• In RDBMS or SQL worlds example – the “primary key” serves as a distinct identifier for each record, ensuring data integrity.
  • Foreign keys establish relationships between tables, linking data across entities.
  • Index keys enhance query performance, enabling swift data retrieval.
  • Composite keys combine multiple attributes to create a unique identifier.

• In No SQL Unique Keys identify documents or entries within a collection, ensuring data integrity.
  • In document-oriented databases, like MongoDB, keys often include a unique identifier, such as the document’s “_id.”
  • In key-value stores, like Redis, keys serve as direct access points to values.
  • NoSQL databases may also use composite keys or secondary indexes for diverse query patterns.
  • Keys are crucial for optimizing data access, retrieval, and navigation in NoSQL databases, contributing to performance in managing various data structures and relationships.

Benefits of Data Modeling

Below are the top-level benefits of data modeling.

• Creating a structure for collaboration between your IT and business teams.

• Revealing opportunities for improving business processes by defining data needs and uses.

• Saving time and money on IT and process investments through appropriate planning.

• Reducing errors (and error-prone redundant data entry) while improving data integrity.

• Increasing the speed and performance of data retrieval and analytics by planning for capacity and growth.

• Setting and tracking target key performance indicators tailored to your business objectives.

Data modeling Tools

Here are a few useful tools for Data modeling examples:

• erwin Data Modeler is a data modeling tool based on the Integration DEFinition for information modeling (IDEF1X) data modeling language that now supports other notation methodologies, including a dimensional approach.

• Enterprise Architect is a visual modeling and design tool that supports the modeling of enterprise information systems and architectures. It’s based on object-oriented languages and standards.

• ER/Studio is database design software that’s compatible with several of today’s most popular database management systems. It supports both relational and dimensional data modeling.

• Open Source tools include open-source solutions such as Open ModelSphere.

That’s all! Happy coding!

Does this help you fix your issue?

Do you have any better solutions or suggestions? Please sound off your comments below.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2026) best practices and guidelines for software design and development.

The post What is Data Modelling – Fundamentals and Guidelines first appeared on TheCodeBuzz.

Today in this guidelines section, we will cover a few useful guidelines to get Faster Insert and Update in Entity Framework Core.

Although the performance of SQL or entity framework query is a vast subject and has many aspects which are important.

However, this guideline details some common guidelines for making your read query faster and helping you achieve efficient updating.

Indexing the Fields in SQL

• A powerful method for facilitating effective database searches is indexing.

• Here, you searched through the sorted index first in order to increase performance rather than running a full database scan (scanning through everything).

• It’s the most effective way to manage the database scan.

• Allows you to effectively manage the scanning of each document. Please be aware that every single document in a collection will undergo a thorough scan if there are no indexes.

• It gives a query the ability to focus results set using the index.

• Indexing improved the efficiency of queries.

Indexes as AntiPattern in SQL query

• Don’t create Indexes that are not used or used rarely.

• Build indexes on only fields that are used often in the query.

• Use Composite indexes for filtering multiple columns.

• Avoid duplicate indexes.

Schema Modelling for Database

Your DB Schema modeling normalization plays important role in the performance of EFCore queries.

You need to perform Normalization and denormalization of domain entities and create them appropriately even before you could load the data the first time.

The benefits of schema modeling are as below,

• Optimize the query performance.

• Help you focus on reading and writing only selected domain entities.

• Eliminate heavy use of joins or evaluation of queries.

Break your class into small class entities.

The below example gives a small glimpse of what is expected by schema modeling.

Below Employee class is broken into small entities like Employee, Contact, SocialSecurity, etc.

Read Optimization – Don’t Load the entire Entity in the Application Memory

An Entity consists of multiple properties which are internally mapped to multiple columns in a respective Database table.

Below Example loads entire Employee entities.

Let’s say an example: If Employee has 100 columns then EF will load all 100 columns even if they are not used.

 foreach (var employee in _context.Employee)
            {
                /// Do something here 
                Console.WriteLine("EmployeeID : " + employee.EmployeeId);
            }
            _context.SaveChanges();

It’s not recommended to load the DB Context entity entirely in memory due to the below issues,

• It could cause huge memory problems if you are loading the entire Entity set (if not aware of the size of the set).  This brings all the Employee row data to the client side causing performance issues.

• Loading unnecessary data could add additional load for processing the queries.

We can optimize the above code by using the Select below,

Content-Based Optimization – Limit your query resultset

• Another optimization technique is to limit the resultset by means of some matching filter.

• Use paging or Filter matching criteria can be derived using business requirements, if possible.

• Content-based loading will let you Load only data that is much sufficient to serve the purpose. Exa UI-based application.

Update Optimization: Use of BulkUpdate

EFCore doesn’t support bulk updates as of now.

But below is the example that developer tends to write.

Here we are going to add preceding zeros to all employee’s ID fields using EFCore.

     foreach(var employee in _context.Employee)
            {
                employee.EmployeeId = employee.EmployeeId.PadRight(4, '0');
                Console.WriteLine("EmployeeID : " + employee.EmployeeId);
                _context.SaveChanges();
            }
            

In the above code,

• The first database roundtrip is performed by code _context.Employee brings all employee data on client-side code execution.

• The second database round trip is performed to save the changes. However 2nd roundtrip can be further optimized into a few more round trips depending on the database provider type and the amount of data.

• _context.SaveChanges() is being called for every record which could affect the performance.

The above code can be further optimized by calling SaveChanges at the end of foreach loop.

The second option can be further optimized as below by calling a raw stored procedure

_context.Employee.FromSqlRaw("UPDATE [EmployeeDB] SET [EmployeeId] =  RIGHT( '0000' + EmployeeId, 4)");

Hope you find these guidelines useful. We will see some more guidelines in the next updates. Hence kindly stay tuned!

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2026) best practices and guidelines for software design and development.

The post Faster Insert and Update in Entity Framework Core – Guidelines first appeared on TheCodeBuzz.

Today in this article, we will discuss MongoDB Security guidelines and Best practices.

Security measures can be applied while data is at rest i.e. storage level security and while data is at the move.

Obviously, Security is not an afterthought process. You must build your system considering the security and risk exposure. You also need to design a risk mitigation process just in case there is a need.

As with all software, MongoDB administrators must consider security and risk exposure for a MongoDB
deployment.

We will cover the below aspects in today’s article,

User Rights Management – Enable Authentication and Authorization

Control access to sensitive data authentication and authorization at the database level.

Define permissions for a user or application and define what data the application or user can access.

Provision users defined roles defining different entities accessing and managing the data.

• Restrict write access at the application level or admin level.

• Restrict access as ReadOnly for non-admin members.

Use any custom authorization or leverage LDAP level integration to verify (the user using a centralized Server.)

Protect Sensitive Data at Rest – Encryption and Decryption

Protecting data at rest in persistent storage is important. Field-level encryption is recommended for protecting any PII, or PHI, or PFI information.

Leverage MongoDB-supported encryption and decryption mechanism.

• Field-level encryption is supported for MongoDB 4.2 and onwards support.

• With client-side field-level encryption, developers can encrypt fields on the client side.

• Encrypt fields are supported without any server-side configuration or directives.

• Client-side field-level encryption in the .NET/C# driver is currently only supported on x64-compatible CPUs.

For more details visit,

• MongoDB Encryption- Field Level Encryption and Decryption C#

Protect Data in Transit

The below guidelines are more generic but ideal for most scenarios to implement secured data transfer.

• Implement encryption to protect the integrity of data when data transit for two-way communications.

• Enforce user-defined encryption requirements based on the enterprise’s organizational and compliance requirements by following standards, guidelines, and best practices.

• Add Encryption of data in transit using TLS v1.2, and above cipher suites for all publicly accessible sites or APIs or Applications.

• TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are the primary means to over the wire or in-transit data.

• Enforce HTTPS-secured transport protocol for accessing websites, API and database connection, etc.

Data Monitoring or Database activity monitoring (DAM)

• Monitor Data Base Access using Health check monitoring tools if any.

• Whitelist and Backlist of IP and environment to control enterprise access.

• Detect any anomalies or attempts to move data outside of defined boundaries.

• Monitor Databases against malicious activity by firewalls and intrusion.

• Audit and monitor all database activity separately, such as privileged user activities and SELECT transactions, without a loss of performance.

• Produce notifications or alerts when a policy violation is identified.

• Prevent tampering or manipulation of database logs.

• Use of Database activity monitoring (DAM) tool (if suitable ) can be used to report any identify and report fraudulent, illegal, or other undesirable behavior.

Implement secure key and certificate management

• Implement secure key and certificate management process.

• Store keys and certificates securely.

• Apply strict access control on key access.

Restrict Network Access

• Secure network access to your MongoDB server. Configure firewall and RBAC to allow connection only from Authorized IPs or networks.
• Follow the Principle of Least Privilege.
• Restrict administrative access to a limited number of trusted personnel.

Upgrade to the Latest MongoDB version

• Plan and be ready to regularly update MongoDB to the latest stable version.
• New releases often include security patches and bug fixes, so staying up to date helps protect against known vulnerabilities.

Implement – Data backup policy

• Implement a regular backup strategy to ensure a copy of your data is available in case of data loss, data corruption, or any security incidents happens.

• Follow backup best practices, such as storing backups in secure locations and testing the restoration process.

Implement – Disaster Recovery plan

Implement a robust disaster recovery strategy. It is important along with regular backup of MongoDB data to a secure place.

Your downtime and recovery time should address your enterprise application requirements which may be dependent on multiple factors.

Perform Security Audits

Conduct security audits and vulnerability assessments to identify and address any security weaknesses in your MongoDB deployment.

This can include performing penetration testing, code reviews, and infrastructure assessments.

Summary

Security is not an afterthought process in fact it is an ongoing process, and it’s important to stay alert and assertive in managing and improving the security of your MongoDB Database.

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2026) best practices and guidelines for software design and development.

The post MongoDB Security guidelines and best practices first appeared on TheCodeBuzz.