{"id":106993,"date":"2025-06-09T15:07:19","date_gmt":"2025-06-09T15:07:19","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=106993"},"modified":"2026-04-08T10:30:38","modified_gmt":"2026-04-08T10:30:38","slug":"tempdb-resource-governor-space-controls-in-sql-server-2025","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/tempdb-resource-governor-space-controls-in-sql-server-2025\/","title":{"rendered":"TempDB Resource Governor Space Controls in SQL Server 2025: A Complete Guide"},"content":{"rendered":"\n

This article was updated in September 2025<\/em> following the SQL Server 2025 (17.x) Preview<\/a> release.<\/em><\/p>\n\n\n\n

TempDB<\/code> is a system database in SQL Server<\/a> that manages temporary objects for all databases on a server. Because it is a shared resource, it can easily become a performance bottleneck, as well as an opportunity for a single database or even a single query to wreck SQL Server performance.<\/p>\n\n\n\n

Because of this, administrators will often give TempDB<\/code> plenty of space and put its files on the fastest storage available. Even with these precautions, it is still possible for a TempDB<\/code>-hungry workload to hog space and resources that result in latency or timeouts for end users.<\/p>\n\n\n\n

SQL Server 2025<\/a> introduces the ability to use Resource Governor<\/a> to help manage TempDB<\/code> resources automatically. This article dives into the new feature, how to configure it, and how it can effectively manage TempDB<\/code>-heavy workloads.<\/p>\n\n\n\n

Background<\/h2>\n\n\n\n

SQL Server stores a variety of data that is temporary in nature. This data is used in query processing, as well as in managing isolation levels and transactions. To illustrate the variety of uses that TempDB<\/code> has, the following is a list of many of the types of objects stored there:<\/p>\n\n\n

\n
    \n
  • Temporary tables & Table Variables <\/li>\n\n\n\n
  • Temporary Stored Procedures <\/li>\n\n\n\n
  • Cursors <\/li>\n\n\n\n
  • Result sets returned by table-valued functions <\/li>\n\n\n\n
  • Worktables and work files <\/li>\n\n\n\n
  • Intermediate sort results <\/li>\n\n\n\n
  • Index rebuilds that use the SORT_IN_TEMPDB<\/code> option <\/li>\n\n\n\n
  • Row versions and version stores <\/li>\n<\/ul>\n<\/div>\n\n\n

    This list has grown significantly over the years as more features have been added to SQL server. Because TempDB<\/code> is simply another database that is stored just like any other database, it can easily be a bottleneck and single-point-of-failure for a SQL Server.<\/p>\n\n\n\n

    If TempDB<\/code> space is exhausted and subsequent queries\/processes cannot allocate space, then they will fail. This is the worst-case scenario that will mean some amount of downtime or errors for an application relying on this SQL Server. Inconsistent behavior will persist until the TempDB<\/code> problem is resolved.<\/p>\n\n\n\n

    Up until now, managing TempDB<\/code> workloads was often a balance of:<\/p>\n\n\n

    \n
      \n
    • Give TempDB<\/code> more space\/files <\/li>\n\n\n\n
    • Write custom monitoring\/management procedures to deal with runaway workloads <\/li>\n<\/ul>\n<\/div>\n\n\n

      The first of these options is easy but can be expensive and become inadequate as workloads grow in both size and complexity. The second option requires extensive administrative experience and may be challenging to implement effectively.<\/p>\n\n\n\n

      A built-in option to assist managing TempDB<\/code> is a welcome addition to SQL Server and one that could greatly aid administrators that are struggling with TempDB<\/code> resource contention or queries that cause runaway TempDB<\/code> growth.<\/p>\n\n\n\n

      Brief Overview of Resource Governor<\/h2>\n\n\n\n

      Resource Governor is a mature feature that debuted all the way back in SQL Server 2008. Because of the complexity of effectively managing workloads at runtime, there is a bit of a learning curve when implementing Resource Governor. The following is a quick guide to getting started, which will help us get ready to use it with TempDB<\/code>. If you are already a Resource Governor pro, then feel free to skip ahead to the next section.<\/p>\n\n\n\n

      By default, Resource Governor is disabled. This can be seen visually in SQL Server Management Studio:<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      <\/p>\n\n\n\n

      The feature may be enabled by executing the following T-SQL:<\/p>\n\n\n\n

      ALTER RESOURCE GOVERNOR RECONFIGURE;<\/pre><\/div>\n\n\n\n
      If there were any previous active configurations in Resource Governor, then enabling it like this will re-enable all those prior settings.<\/p>\n\n\n\n
      Once enabled, there are three basic features that go into using it, each with a distinct purpose:<\/p>\n\n\n
      \n
        \n
      •  Resource Pools <\/li>\n\n\n\n
      •  Workload Groups <\/li>\n\n\n\n
      •  Classifier Functions <\/li>\n<\/ul>\n<\/div>\n\n\n
        Resource Pools<\/h3>\n\n\n\n
        A resource pool is a logical container for a server\u2019s physical resources. By default, a server will contain an internal resource pool and a default resource pool. You may create more based on a server\u2019s configuration and complexity.<\/p>\n\n\n\n
        For the simplest of applications, using the default resource pool is perfectly fine. For larger servers with multiple applications and SLAs, there may be a need to have multiple resource pools available to separately manage those different use-cases.<\/p>\n\n\n\n
        Note that all queries to configure resource governor are run against the master<\/em> database.<\/p>\n\n\n\n
        The following T-SQL creates a new resource pool:<\/p>\n\n\n\n
        USE master;\nCREATE RESOURCE POOL DemoPool\nWITH\n(   MAX_CPU_PERCENT = 75,\n    MAX_MEMORY_PERCENT = 50);<\/pre><\/div>\n\n\n\n
        Note that this example limits CPU usage to 75% and memory usage to 50% for these workloads. This query returns details on all resource pools:<\/p>\n\n\n\n
        SELECT *\nFROM sys.resource_governor_resource_pools<\/pre><\/div>\n\n\n\n
        The results show the default resource pools, as well as the one we just created:<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        <\/p>\n\n\n\n
        Workload Groups<\/h3>\n\n\n\n
        A workload group is linked to a resource pool and is used to classify sessions. If you are only using a single resource pool, then this is trivial, but if you are using multiple resource pools, then each workload group would correspond to an application or set of applications.<\/p>\n\n\n\n
        The following query creates a new workload group and assigns it to the resource pool created earlier:<\/p>\n\n\n\n
        CREATE WORKLOAD GROUP DemoGroup\nUSING DemoPool;<\/pre><\/div>\n\n\n\n
        Another DMV can be used to list the current workload groups defined on this server:<\/p>\n\n\n\n
        SELECT *\nFROM sys.resource_governor_workload_groups;<\/pre><\/div>\n\n\n\n
        The output shows the internal and default workload groups, as well as the one just created:<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        <\/p>\n\n\n\n
        Note that the statistics in this view are reset on server restart, but can also be reset using the following T-SQL:<\/p>\n\n\n\n
        ALTER RESOURCE GOVERNOR RESET STATISTICS;<\/pre><\/div>\n\n\n\n
        Classifier Functions<\/h3>\n\n\n\n
        The last basic component of resource governor is the classifier function. These functions return the name of a workload group based on the session of the application\u2019s connection. Its contents can be whatever is typically allowed in a scalar user-defined function, though it is generally preferable to keep things as simple as possible. Therefore, a simple IF<\/code>\/THEN<\/code>\/ELSE<\/code> or CASE<\/code> structure is ideal when possible.<\/p>\n\n\n\n
        The following is a simple classifier function that checks for a single app name and returns our DemoGroup<\/em> workload group when matched. Otherwise, the default workload group is used:<\/p>\n\n\n\n
        USE master;\nGO\n\nCREATE FUNCTION dbo.DemoClassifierFunction()\nRETURNS SYSNAME\nWITH SCHEMABINDING\nAS\nBEGIN\n    IF (APP_NAME() = 'EdsCoolDemoApp')\nBEGIN\n        RETURN 'DemoGroup';\nEND\n    RETURN 'default';\nEND;<\/pre><\/div>\n\n\n\n
        Once created, a classifier function must be activated:<\/p>\n\n\n\n
        ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.DemoClassifierFunction);\nALTER RESOURCE GOVERNOR RECONFIGURE;<\/pre><\/div>\n\n\n\n
        The details of classifier functions can be pulled using another system view query:<\/p>\n\n\n\n
        SELECT\n       resource_governor_configuration.classifier_function_id,\n       resource_governor_configuration.is_enabled,\n       objects.[name] AS function_name,\n       sql_modules.[definition] AS function_definition\nFROM sys.resource_governor_configuration\n      INNER JOIN sys.objects\nON resource_governor_configuration.classifier_function_id = objects.[object_id]\n      INNER JOIN sys.sql_modules\nON objects.[object_id] = sql_modules.[object_id];<\/pre><\/div>\n\n\n\n
        The results show the basics of the function we created:<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        <\/p>\n\n\n\n
        The results confirm that the function is enabled, and the definition is added in for posterity. There are other columns available in each view that may be helpful for troubleshooting or documentation purposes, as well.<\/p>\n\n\n\n
        Note that the classifier function must be created in the master<\/em> database. This ensures it is available for all connections and databases.<\/p>\n\n\n\n
        Configuring Resource Governor for TempDB<\/h2>\n\n\n\n
        With the absolute basics of Resource Governor out of the way, the next step is to introduce how it is used by TempDB<\/code>. It is important to note that the ONLY metric that can be bound by Resource Governor is data space used.<\/p>\n\n\n\n
        TempDB<\/code> log space cannot be managed here – but that is OK! Why? Starting in SQL Server 2025, Accelerated Database Recovery (ADR) can be enabled on <\/em><\/strong>TempDB<\/code>. The aggressive log truncation provided by ADR greatly reduces log space usage and churn in TempDB<\/code>. Because TempDB<\/code> is a temporary data store, the recovery aspects of ADR become irrelevant, making this an ideal feature to test and enable on TempDB<\/code>!<\/p>\n\n\n\n
        Because Resource Governor has limited usage for TempDB<\/code>, the amount of work needed to configure it is less than for other databases and metrics.<\/p>\n\n\n\n
        To begin, the default workload group will be adjusted to allow for a maximum of 20,000MB of data space for TempDB:<\/p>\n\n\n\n
        ALTER WORKLOAD GROUP [default] WITH (GROUP_MAX_TEMPDB_DATA_MB = 20000);\nALTER RESOURCE GOVERNOR RECONFIGURE;<\/pre><\/div>\n\n\n\n
        This executes successfully and the resulting configuration change can be confirmed with this query:<\/p>\n\n\n\n
        SELECT\ngroup_id,\n[name],\ngroup_max_tempdb_data_mb\nFROM sys.resource_governor_workload_groups;<\/pre><\/div>\n\n\n\n
        This will return:<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        <\/p>\n\n\n\n
        Joining a few views together allows for efficient review of both the configuration setting and usage for the default workgroup:<\/p>\n\n\n\n
        SELECT dm_resource_governor_workload_groups.group_id,\n       dm_resource_governor_workload_groups.[name],\n       resource_governor_workload_groups.group_max_tempdb_data_mb,\n       dm_resource_governor_workload_groups.total_tempdb_data_limit_violation_count,\n       dm_resource_governor_workload_groups.tempdb_data_space_kb,\n       dm_resource_governor_workload_groups.peak_tempdb_data_space_kb\nFROM sys.dm_resource_governor_workload_groups\n      INNER JOIN sys.resource_governor_workload_groups\n         ON dm_resource_governor_workload_groups.[name] =\n                                resource_governor_workload_groups.[name]\nWHERE dm_resource_governor_workload_groups.[name] = 'default';<\/pre><\/div>\n\n\n\n
        The results of this query are quite useful:<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        <\/p>\n\n\n\n
        Not only is the max TempDB<\/code> data space setting shown here, but usage numbers are provided that indicate:<\/p>\n\n\n
        \n
          \n
        •  The current TempDB<\/code> data space limit (tempdb_data_space_kb)<\/code> <\/li>\n\n\n\n
        •  The maximum TempDB<\/code> data space used since the last restart (peak_tempdb_data_space_kb<\/code>) <\/li>\n\n\n\n
        •  The number of times the data space limit was exceeded, triggering the Resource Governor to end the transaction (total_tempdb_data_limit_violation_coun<\/code>t<\/em>) <\/li>\n<\/ul>\n<\/div>\n\n\n
          Note that the usage numbers are in kilobytes, which I retained here to show granularity when usage was low.<\/p>\n\n\n\n
          In addition to specifying a hard-coded space limit for TempDB<\/code> data files, a percentage can be used instead. This allows Resource Governor to limit usage based on a given percentage of the allocated data space, like this:<\/p>\n\n\n\n
          ALTER WORKLOAD GROUP [default] WITH (GROUP_MAX_TEMPDB_DATA_PERCENT = 50, GROUP_MAX_TEMPDB_DATA_MB = NULL);\nALTER RESOURCE GOVERNOR RECONFIGURE;\n<\/pre><\/div>\n\n\n\n
          Note that both options cannot be used at once for one workload group. Either GROUP_MAX_TEMPDB_DATA_MB<\/code> is set or GROUP_MAX_TEMPDB_DATA_PERCENT<\/code> is set. Configuring both will automatically disable the GROUP_MAX_TEMPDB_DATA_PERCENT<\/code> setting and an informational message will be returned that looks like this:<\/p>\n\n\n\n
          GROUP_MAX_TEMPDB_DATA_PERCENT is not in effect because tempdb configuration requirements aren’t met. For more information, see https:\/\/go.microsoft.com\/fwlink\/?linkid=2322219.<\/em><\/p>\n\n\n\n
          Viewing information from sys.resource_governor_workload_groups allows the detailed settings for both configurations to be validated:<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          <\/p>\n\n\n\n
          This shows that a query run in this workload group will be allowed to consume up to 50% of the TempDB<\/code> data space available, after which no more space will be allocated.<\/p>\n\n\n\n
          Being able to limit usage by percentage is quite useful as space allocated to TempDB<\/code> can change, and hard-coded values in megabytes will not automatically adjust, if needed. Microsoft notes some requirements for using percentages for this purpose:<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          Those limitations are straightforward as they handle scenarios where a percentage cannot be calculated with precision.<\/p>\n\n\n\n
          Testing TempDB Resource Governor<\/h2>\n\n\n\n
          To test TempDB<\/code> resource governance, the workgroup, resource pool, and classifier function from earlier will be used. Note that the app name that will be routed to the DemoGroup<\/code> is the app \u201cEdsCoolDemoApp<\/code>\u201d. To actively query as this app, the connection will be changed from SQL Server Management Studio:<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          <\/p>\n\n\n\n
          From the dialog window, the name of the app will be entered in the additional connection parameters:<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          <\/p>\n\n\n\n
          When connected, the current app name and associated workload group can be verified with this T-SQL:<\/p>\n\n\n\n
          SELECT APP_NAME() AS AppName;\n\nSELECT dm_resource_governor_workload_groups.[name] AS WorkloadGroupName\nFROM sys.dm_exec_sessions\n        INNER JOIN sys.dm_resource_governor_workload_groups\n           ON dm_exec_sessions.group_id =\n                           dm_resource_governor_workload_groups.group_id\nWHERE dm_exec_sessions.session_id = @@SPID;<\/pre><\/div>\n\n\n\n
          The results provide the expected result (phew!):<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          <\/p>\n\n\n\n
          To make for a speedy demo, the DemoGroup<\/em> will be adjusted to have a 2MB TempDB<\/code> data space limit:<\/p>\n\n\n\n
          ALTER WORKLOAD GROUP DemoGroup WITH (GROUP_MAX_TEMPDB_DATA_MB = 2);\nALTER RESOURCE GOVERNOR RECONFIGURE;<\/pre><\/div>\n\n\n\n
          The following query verifies the current TempDB<\/code> configuration for this workgroup:<\/p>\n\n\n\n
          SELECT dm_resource_governor_workload_groups.group_id,\n       dm_resource_governor_workload_groups.[name],\n       resource_governor_workload_groups.group_max_tempdb_data_mb,\n       dm_resource_governor_workload_groups.total_tempdb_data_limit_violation_count,\n       dm_resource_governor_workload_groups.tempdb_data_space_kb,\n       dm_resource_governor_workload_groups.peak_tempdb_data_space_kb\nFROM sys.dm_resource_governor_workload_groups\n      INNER JOIN sys.resource_governor_workload_groups\n         ON dm_resource_governor_workload_groups.[name] =\n                              resource_governor_workload_groups.[name]\nWHERE dm_resource_governor_workload_groups.[name] = 'DemoGroup';<\/pre><\/div>\n\n\n\n
          The results are as follows:<\/p>\n\n\n\n
          \"\"\/<\/figure>\n\n\n\n
          <\/p>\n\n\n\n
          To test the new setting, a query will be run that populates a temporary table:<\/p>\n\n\n\n
          SELECT *\nINTO #TempTableTest\nFROM sys.sql_modules;<\/pre><\/div>\n\n\n\n
          When executed, an error message is returned:<\/p>\n\n\n\n
          Msg 1138, Level 17, State 1, Line 177<\/p>\n\n\n\n
          Could not allocate a new page for database ‘tempdb’ because that would exceed the limit set for workload group ‘DemoGroup’.<\/p>\n\n\n\n
          Note that by running the workload group DMV validation query from above, the failure from above can be confirmed:<\/p>\n\n\n\n
          \"\"\/<\/figure>\n\n\n\n
          The results show that the violation count has been incremented by one and that the peak TempDB data space used was exactly 2MB, which was the cap that was configured prior to this demo.<\/p>\n\n\n\n
          A fun additional query to run after the failure:<\/p>\n\n\n\n
          SELECT * FROM #TempTableTest;<\/pre><\/div>\n\n\n\n
          The results are as follows:<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n

            
          This shows that the table contains nothing. WAIT! What table? Why does the temporary table exist if the SELECT INTO<\/code> statement failed? This is, in fact, standard behavior and not an anomaly.<\/p>\n\n\n\n
          SELECT INTO<\/code> is really the combination of CREATE TABLE<\/code> and SELECT<\/code>. The Resource Governor failure occurred during the SELECT<\/code> portion of the query, after the temporary table was created. Therefore, if a TRY\u2026CATCH<\/code> attempts to recreate the table after the failure, the result will be an error indicating that the table already exists. This is a bit of an edge-case, but worth mentioning as it can impact more complex processes.<\/p>\n\n\n\n
          Disabling Resource Governor<\/h2>\n\n\n\n
          As with any feature, there may be a need to disable part or all of it. This is (luckily) straightforward! To disable TempDB<\/code> resource governance, the following T-SQL may be used:<\/p>\n\n\n\n
          ALTER WORKLOAD GROUP DemoGroup\nWITH (GROUP_MAX_TEMPDB_DATA_MB = NULL);<\/pre><\/div>\n\n\n\n
          This is run separately on each workload group. Therefore, if multiple workload groups are configured and in-use, be sure to disable TempDB<\/code> resource governance on all that are no longer to be used for this purpose. All other Resource Governor features will continue to operate normally after this is executed.<\/p>\n\n\n\n
          Workload groups, resource pools, and classifier functions can be dropped when no longer needed. Ensure that they are dropped in an order such that no dependencies are violated. For example, if a workload group relies on a resource pool, then the workload group must be dropped first, prior to the resource pool.<\/p>\n\n\n\n
          The following script drops the various objects created during the demos in this article:<\/p>\n\n\n\n
          DROP WORKLOAD GROUP DemoGroup;\nDROP RESOURCE POOL DemoPool;\nDROP FUNCTION dbo.DemoClassifierFunction;<\/pre><\/div>\n\n\n\n
          Oops! An error is thrown when this executes:<\/p>\n\n\n\n
          Msg 10920, Level 16, State 1, Line 199<\/p>\n\n\n\n
          Cannot drop user-defined function ‘DemoClassifierFunction’. It is being used as a resource governor classifier.<\/p>\n\n\n\n
          Classifier functions are bound to Resource Governor and need to be removed prior to dropping them. The following script will accomplish this:<\/p>\n\n\n\n
          ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = NULL);\nRECONFIGURE\n\nDROP FUNCTION dbo.DemoClassifierFunction;<\/pre><\/div>\n\n\n\n
          This results in glorious success! Finally, if there is a need to fully disable Resource Governor, that can be done like this:<\/p>\n\n\n\n
          ALTER RESOURCE GOVERNOR DISABLE;<\/pre><\/div>\n\n\n\n
          Notes on Resource Governor for TempDB<\/h2>\n\n\n\n
          Determining whether to limit TempDB<\/code> space by an amount of megabytes or a percentage is up to the operator, but each scenario lends itself to specific types of workloads:<\/p>\n\n\n
          \n
            \n
          • Limiting by maximum allowable space used<\/strong>: Workloads with known attributes that are static and rarely change, or servers that are not expected to change much over time. Alternatively, if this is a setting you want to manage manually, then this allows for quick fine-tuning as needed.<\/li>\n\n\n\n
          • Limiting by a percentage of space allocated<\/strong>: When workloads are expected to increase in size over time, or they are variable enough that TempDB<\/code> configurations are likely to change periodically, then limiting usage to a percentage can ensure that queries cannot hog too much space, even when that space fluctuates over time.<\/li>\n<\/ul>\n<\/div>\n\n\n
            For more and more servers today, TempDB<\/code> is given a massive amount of space \u2013 more than most reasonable queries could ever need. If you have an environment like that, then Resource Governor is there to protect against rogue\/buggy queries more than anything else. Your choice of how to limit usage is a bit less consequential as the numbers will be quite large, regardless of which method is used.<\/p>\n\n\n\n
            If the correct method is not clear, testing both is not an invalid way to determine the ideal settings. Limits can be easily tested in development and QA environments to figure out a reasonable baseline to begin with.<\/p>\n\n\n\n
            Conclusion<\/h2>\n\n\n\n
            Resource Governor gets a fresh breath of air with this long-desired feature edition! No longer do administrators need to cobble together scripts and processes to manage TempDB<\/code>. TempDB<\/code> resource governance is easy to configure and use when compared to other components of Resource Governor.<\/p>\n\n\n\n
            I expect TempDB<\/code> monitoring to become far simpler in the future with this addition. As a bonus, out-of-the-box solutions are easier to use and maintain than customized solutions that we need to put together and manage. For those who have never used Resource Governor before, or who shied away from it due to its complexity, managing TempDB with it is quite easy.<\/p>\n\n\n\n
            Once running SQL Server 2025, give this new feature a try! If you have never managed TempDB<\/code> space before, this provides an easy way to do so, even without extensive SQL Server domain knowledge.<\/p>\n\n\n\n
            Do you have any experiences with TempDB monitoring with (or without) Resource Governor? If so, let me know!<\/p>\n","protected":false},"excerpt":{"rendered":"
            SQL Server 2025 introduces the ability to use Resource Governor to help manage TempDB resources automatically. This article dives into the new feature, how to configure it, and how it can effectively manage TempDB-heavy workloads.…<\/p>\n","protected":false},"author":329827,"featured_media":107008,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143527,143523,143524],"tags":[4151,159254,159319],"coauthors":[101655],"class_list":["post-106993","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-administration-sql-server","category-databases","category-sql-server","tag-sql-server","tag-sql-server-2025","tag-sqlserver2025publicpreview"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/106993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/329827"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=106993"}],"version-history":[{"count":5,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/106993\/revisions"}],"predecessor-version":[{"id":109461,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/106993\/revisions\/109461"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media\/107008"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=106993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=106993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=106993"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=106993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}