"[docs] remove leftovers of Yandex Cloud specific docs"

"[docs] remove leftovers of Yandex Cloud specific docs"

Pull Request resolved: #182

25 files changed, 1 insertions, 224 deletions

diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md
index a6e18f090ed..e69de29bb2d 100644
--- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md
+++ b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md
@@ -1,17 +0,0 @@
----
-title: Serverless and Dedicated modes in YDB
-description: "YDB databases can be created in two modes Dedicated and Serverless. Dedicated mode of operation assumes that resources for Tablet instances and for executing YQL queries are selected from resources explicitly allocated for the compute database. In the Serverless mode of operation, the YDB infrastructure determines how many computing resources need to be allocated to service the user base."
-keywords:
-  - ydb
-  - serverless
-  - dedicated
-editable: false
----
-# Serverless and Dedicated modes {{ ydb-short-name }}
-
-You can create and use multiple {{ ydb-short-name }} databases. When creating a database, one of two operating modes is selected for each database: Serverless or Dedicated. The mode can't be changed later.
-
-* _Serverless_: A DB that doesn't require you to configure, administer, or monitor load or manage resources. To create a database, you only need to enter a name, and you'll get the URL for the connection. Payment is charged for the execution of queries and the actual amount of stored data.
-
-* _Dedicated_: You determine the computing resources that will be reserved for the database: CPU and RAM on the nodes, the number of nodes, and the storage size. You need to make sure there are sufficient resources to handle the load and add more when necessary. Payment is charged for dedicated resources per hour, regardless of their actual use.
-
diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
index 33130369fea..e69de29bb2d 100644
--- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
+++ b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
@@ -1,42 +0,0 @@
-## Serverless database parameters {#serverless-options}
-
-### Limitation: Throughput, RU/s {#capacity}
-
-When executing a query to the serverless database, an indicator is calculated that shows the amount of resources of various types used to execute this query. This indicator is measured in Request Units (RUs). The cost of operating a serverless database depends on the total consumption of RUs.
-
-Because serverless database resources are indefinitely large, the maximum consumption of RUs over a period of time can also be any value, leading to surprisingly high charges. For example, this can happen as a result of an error in the code causing an infinite loop of queries.
-
-With the cloud deployment of {{ ydb-short-name }}, there is a limit on the total number of RUs per second at the level of cloud quotas. But this limit is technical and large enough that the potential invoice amount can still be significantly higher than expected. You can only increase this parameter by contacting technical support.
-
-The **Throttling limit** on a serverless database allows you to set the maximum consumption rate of RUs per second. Considering a 5-minute accumulation of unused RUs, even with small limits (10 RU/s by default when creating a database), you can successfully perform various development and testing tasks and run applications with a small load. At the same time, the amount of possible charges will be limited to an upper limit of 2572000 seconds per month (30 days) multiplied by the price per 1 million RUs. Based on the pricing policy as of the date of this documentation (₽13.36), the maximum possible amount of charges per month is about ₽340.
-
-You can change the **Throttling limit** interactively at any time, both increasing and decreasing it without restrictions. This allows you to quickly adjust it as needed, for example, to run a load test. Interactive means that changes take effect with the minimum technological delay required to propagate information about the new value across {{ ydb-short-name }} nodes.
-
-The **Throttling limit** can be set to zero, which will cause overloading exceptions on any query. This can be useful for testing your application's response to such an exception and to prevent the consumption of resources if your application gets out of control.
-
-The **Throttling limit** can be enabled or disabled. We recommend that you always keep it enabled, but disabling it may be useful if you need to temporarily get the maximum possible performance from the database, for example, to process a batch of queries.
-
-**Specifics of using the throttling limit, RU/s**
-
-If the limit is exceeded, a query is not accepted for execution and the `Throughput limit exceeded` error is returned. This error means that you can safely resend your query later. We recommend that you use the statements supplied as part of the {{ ydb-short-name }} SDK when re-sending. The proposed statements implement repetition algorithms that use different repetition strategies depending on error type and code: zero delay, exponentially increasing delay, fast or slow repetition, and others.
-
-The limit is triggered with some delay, so the `Throughput limit exceeded` error is returned for a subsequent query rather than the specific query that resulted in exceeding the limit. Once the limit is triggered, queries won't be accepted for execution for a period approximately equal to the ratio of the queries exceeding the limit to the limit itself. For example, if you use 1000 RUs for the execution of a single query while your limit is 100 RUs/sec, new queries won't be accepted for 10 seconds.
-
-To reduce the risk of rejection under uneven load, {{ ydb-short-name }} flexibly applies restrictions using a bandwidth reservation mechanism (`burst capacity`). As long as you use fewer RU processing requests than specified in the restriction, the unused bandwidth is reserved. During peak usage, more bandwidth than specified in the restriction may be temporarily available from the accumulated reserve.
-
-{{ ydb-short-name }} reserves about 5 minutes of bandwidth. The reserve enables you to run a single query with a cost of about `5 min × 60 s × quota RU/s` without subsequent queries being rejected. The `burst capacity` availability policy may be changed.
-
-The quota for the number of serverless queries is also a tool to protect from paying for resource overruns resulting from application faults or attacks on the service. The `burst capacity` mechanism enables you to set the quota to the lowest value at which your application works without getting any `Throughput limit exceeded` errors and to keep some margin against an unexpected increase in load.
-
-### Limitation: Maximum amount of data {#volume}
-
-When using a Serverless database, the amount you pay depends on the amount of data stored.
-
-Because the storage size in a serverless database is indefinitely large, the maximum amount of data that can be stored can also be any value, leading to surprisingly high charges. For example, this can happen as the result of an error in the code causing an infinite loop of data being added or if you accidentally import the wrong backup.
-
-The **Maximum amount of data** limit for a serverless database limits the amount of data that {{ ydb-short-name }} will allow to add to this database. By default, a limit of 50 GB is set for new databases, which limits your monthly charges for the amount of stored data to approximately ₽650, according to the pricing policy as of the date of this documentation (₽13.41 per GB, 1 GB for free).
-
-You can change the **Maximum amount of data** limit interactively at any time, both via the graphical console and the CLI and raise or reduce it without limitations. This allows you to quickly adjust it as needed.
-
-We don't recommend setting the **Maximum amount of data** limit below the current actual amount because in this state, all data modification operations, including DELETE, become unavailable. You will only be able to reduce the amount of data with the DROP TABLE or DROP INDEX commands. If the limit is accidentally set below the actual volume, we recommend returning it to the operating value exceeding the actual volume with some redundancy.
-
diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
index d396434cd88..e69de29bb2d 100644
--- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
+++ b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
@@ -1,20 +0,0 @@
-## {{ ydb-short-name }} architecture in different modes of operation {#arch-diff}
-
-### Separate compute and storage layers {#separate-layers}
-
-Please note that {{ ydb-short-name }} has two separate explicit layers: storage and compute. The storage layer is responsible for securely storing data on storage devices and replicating data between nodes to ensure fault tolerance.
-
-In {{ ydb-short-name }}, user data is stored in tables that are partitioned. A shard is an entity that is responsible for storing a table partition (typically one). An entity called a tablet is responsible for changing data in a shard. It's a component that implements consistent changes in the shard data and solves the issue of distributed consensus. A tablet instance can be viewed as an object that is generated in the process address space and consumes CPU resources and RAM. Tablets store all their statuses in the storage layer. This means, among other things, that a tablet instance can be raised in an arbitrary process that the storage layer is available from. The {{ ydb-short-name }} compute layer essentially consists of tablets and the YQL query execution layer.
-
-It should be noted that the concept of a database comprises user tables and, accordingly, tablet instances serving these tables as well as certain system entities. For example, there is a tablet called SchemeShard. It serves the data schema of all tables. There is a coordination system for distributed transactions whose items are also tablets.
-
-### {{ ydb-short-name }} Dedicated mode {#dedicated}
-
-Dedicated mode assumes that resources for tablet instances and for executing YQL queries are selected from the compute resources explicitly allocated to the database. Computational resources are VMs that have a certain number of vCPUs and some memory. The task of selecting the optimal amount of resources for the DB is currently the user's responsibility. If there aren't enough resources to serve the load, the latency of requests increases, which may eventually lead to the denial of service for requests, such as that with the `OVERLOADED` return code. The user can add compute resources (VMs) to the database in the UI or CLI to ensure it has the necessary amount of computing resources. Adding compute resources to the DB is relatively fast and comparable to the time it takes to start a VM. Subsequently, {{ ydb-short-name }} automatically balances tablets across a cluster account taken of resources added.
-
-### {{ ydb-short-name }} Serverless mode {#serverless}
-
-In Serverless mode, the {{ ydb-short-name }} infrastructure determines the amount of computational resources to allocate to support a user database. The amount of allocated resources can be either very large (an arbitrary number of cores) or very small (significantly less than one core). If a user created a DB with a single table with a single entry and only rarely makes DB queries, {{ ydb-short-name }} actually uses a small amount of RAM on tablet instances that are part of the user DB. This is possible due to the fact that the user database components are objects rather than processes. If the load increases, the DB components start using more CPU time and memory. If load grows to the point where there aren't enough VM resources, the {{ ydb-short-name }} infrastructure can balance the system granularly spawning tablet instances on other VMs.
-
-This technology lets you package virtual entities (tablet instances) very tightly together into physical resources based on actual consumption. This makes it possible to invoice the user for the operations performed rather than the allocated resources.
-
diff --git a/ydb/docs/en/core/concepts/serverless_and_dedicated.md b/ydb/docs/en/core/concepts/serverless_and_dedicated.md
index a80ceb2658e..e69de29bb2d 100644
--- a/ydb/docs/en/core/concepts/serverless_and_dedicated.md
+++ b/ydb/docs/en/core/concepts/serverless_and_dedicated.md
@@ -1,5 +0,0 @@
-{% include [intro.md](_includes/serverless_and_dedicated/01_intro.md) %}
-
-{% include [sls_pars.md](_includes/serverless_and_dedicated/02_sls_pars.md) %}
-
-{% include [arch_diff.md](_includes/serverless_and_dedicated/10_arch_diff.md) %}
diff --git a/ydb/docs/en/core/concepts/toc_i.yaml b/ydb/docs/en/core/concepts/toc_i.yaml
index 2583de2e5c0..104c7884e8b 100644
--- a/ydb/docs/en/core/concepts/toc_i.yaml
+++ b/ydb/docs/en/core/concepts/toc_i.yaml
@@ -6,7 +6,6 @@ items:
   href: auth.md
 - name: Data model and schema
   include: { path: datamodel/toc_p.yaml, mode: link }
-- { name: Serverless and Dedicated operation modes,   href: serverless_and_dedicated.md }
 - { name: Data types,                            href: datatypes.md, hidden: true } # Deprecated
 - { name: Transactions,                             href: transactions.md }
 - { name: Secondary indexes,                      href: secondary_indexes.md }
diff --git a/ydb/docs/en/core/faq/_includes/all.md b/ydb/docs/en/core/faq/_includes/all.md
index a65c8817554..dfc60f61b53 100644
--- a/ydb/docs/en/core/faq/_includes/all.md
+++ b/ydb/docs/en/core/faq/_includes/all.md
@@ -20,7 +20,3 @@
 
 {% include notitle [yql.md](../yql.md) %}
 
-## Serverless {#serverless}
-
-{% include notitle [serverless.md](../serverless.md) %}
-
diff --git a/ydb/docs/en/core/faq/_includes/index.md b/ydb/docs/en/core/faq/_includes/index.md
index ef38acaf1b2..be82795119d 100644
--- a/ydb/docs/en/core/faq/_includes/index.md
+++ b/ydb/docs/en/core/faq/_includes/index.md
@@ -6,5 +6,4 @@
 {% endif %}
 * [Errors](../errors.md)
 * [YQL](../yql.md)
-* [Serverless](../serverless.md)
 
diff --git a/ydb/docs/en/core/faq/_includes/serverless.md b/ydb/docs/en/core/faq/_includes/serverless.md
index 2922f743310..e69de29bb2d 100644
--- a/ydb/docs/en/core/faq/_includes/serverless.md
+++ b/ydb/docs/en/core/faq/_includes/serverless.md
@@ -1,14 +0,0 @@
-# {{ ydb-short-name }} in Serverless mode
-
-#### How do secondary indexes affect the request cost?
-
-Operations with indexes are estimated according to the same rules as operations with tables. They are reflected in the request statistics and included in the total indicators that are used to calculate the cost in Request Units (RU). Read more in [pricing policy for the serverless {{ ydb-short-name }} API]{% if lang == "en" %}(https://cloud.yandex.com/en/docs/ydb/pricing/request_units_yql){% endif %}{% if lang == "ru" %}(https://cloud.yandex.ru/docs/ydb/pricing/request_units_yql){% endif %}.
-
-When reading data from a table using an index, the request statistics will show the number of rows read from the index and their volume.
-
-When adding a new row to a table, a record is also added to each index that exists in this table, with the number of added records and the volume of written data shown in the statistics.
-
-Whenever a table row update occurs, the statistics will reflect a deletion operation for the old record and an insert for the new one for all indexes that include the fields being updated.
-
-When deleting a table row, the statistics will include the deletion of records from all indexes in this table.
-
diff --git a/ydb/docs/en/core/faq/serverless.md b/ydb/docs/en/core/faq/serverless.md
index 5429ea3430b..e69de29bb2d 100644
--- a/ydb/docs/en/core/faq/serverless.md
+++ b/ydb/docs/en/core/faq/serverless.md
@@ -1 +0,0 @@
-{% include [serverless.md](_includes/serverless.md) %}
diff --git a/ydb/docs/en/core/faq/toc_i.yaml b/ydb/docs/en/core/faq/toc_i.yaml
index cf94b19ec9c..970f3697f69 100644
--- a/ydb/docs/en/core/faq/toc_i.yaml
+++ b/ydb/docs/en/core/faq/toc_i.yaml
@@ -10,11 +10,9 @@ items:
   href: errors.md
 - name: YQL
   href: yql.md
-- name: Serverless
-  href: serverless.md
 - name: All questions on one page
   href: all.md
 # Essintial for build with contributors, as it fails without that
 - name: SDK-Hidden
   href: sdk.md
-  hidden: true
\ No newline at end of file
+  hidden: true
diff --git a/ydb/docs/en/core/troubleshooting/_includes/system_views/query_metrics_header.md b/ydb/docs/en/core/troubleshooting/_includes/system_views/query_metrics_header.md
index 68711228cb9..58b0fac2248 100644
--- a/ydb/docs/en/core/troubleshooting/_includes/system_views/query_metrics_header.md
+++ b/ydb/docs/en/core/troubleshooting/_includes/system_views/query_metrics_header.md
@@ -42,7 +42,3 @@ Table structure:
 | `SumDeleteRows` | Total number of rows deleted.<br>Type: `Uint64`. |
 | `MinDeleteRows` | Minimum number of rows deleted.<br>Type: `Uint64`. |
 | `MaxDeleteRows` | Maximum number of rows deleted.<br>Type: `Uint64`. |
-| `SumRequestUnits` | Total number of [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options) used.<br>Type: `Uint64`. |
-| `MinRequestUnits` | Minimum number of [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options) used.<br>Type: `Uint64`. |
-| `MaxRequestUnits` | Maximum number of [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options) used.<br>Type: `Uint64`. |
-
diff --git a/ydb/docs/en/core/troubleshooting/_includes/system_views/tops_header.md b/ydb/docs/en/core/troubleshooting/_includes/system_views/tops_header.md
index b9eee3210c3..5bc627f7d64 100644
--- a/ydb/docs/en/core/troubleshooting/_includes/system_views/tops_header.md
+++ b/ydb/docs/en/core/troubleshooting/_includes/system_views/tops_header.md
@@ -21,7 +21,6 @@ All tables have the same set of fields:
 --- | ---
 | `IntervalEnd` | The end of a one-minute or one-hour interval.<br>Type: `Timestamp`.<br>Key: `0`. |
 | `Rank` | Rank of a top query.<br>Type: `Uint32`.<br>Key: `1`. |
-| `RequestUnits` | Number of [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options) used. |
 | `QueryText` | Query text.<br>Type: `Utf8`. |
 | `Duration` | Total query execution time.<br>Type: `Interval`. |
 | `EndTime` | Query execution end time. <br>Type: `Timestamp`. |
diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md
index 8fff85f17e3..e69de29bb2d 100644
--- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md
+++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md
@@ -1,17 +0,0 @@
----
-title: Режимы работы Serverless и Dedicated в YDB
-description: "Базы YDB могут быть созданы в двух режимах Dedicated и Serverless. Режим работы Dedicated предполагает, что ресурсы на инстансы Таблеток и на выполнение YQL-запросов выбираются из явно выделенных для базы данных compute ресурсов. В Serverless режиме работы инфраструктура YDB определяет сколько вычислительных ресурсов необходимо выделить для обслуживания пользовательской базы."
-keywords:
-  - ydb
-  - serverless
-  - dedicated
-editable: false
----
-
-# Serverless и Dedicated режимы работы {{ ydb-short-name }}
-
-Вы можете создать и использовать множество баз данных {{ ydb-short-name }}. Для каждой БД при создании выбирается один из двух режимов работы: Serverless или Dedicated. В дальнейшем он не может быть изменен.
-
-* _Serverless_ — база данных, не требующая от вас какого-либо конфигурирования, администрирования, отслеживания загрузки и управления ресурсами. Для ее создания достаточно указать имя, и вы получите URL для соединения. Оплата берется за исполнение запросов и фактический объем хранимых данных.
-
-* _Dedicated_ — вы определяете вычислительные ресурсы, которые будут зарезервированы под базу данных: CPU и RAM на узлах, количество узлов и объем хранилища данных. Вам необходимо отслеживать достаточность ресурсов для успешной обработки нагрузки и добавлять новые по мере необходимости. Оплата берется за выделенные ресурсы по часам, вне зависимости от их фактического использования.
diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
index bad966810bc..e69de29bb2d 100644
--- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
+++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md
@@ -1,42 +0,0 @@
-
-## Параметры Serverless базы данных {#serverless-options}
-
-### Ограничения — пропускная способность, RU/с {#capacity}
-
-При исполнении запроса к Serverless базе данных вычисляется показатель, отражающий величину ресурсов разного вида, затраченных на исполнение этого запроса. Данный показатель измеряется в специальных единицах — Request Units (RU). От суммарного потребления RU зависит стоимость использования Serverless базы данных.
-
-Так как ресурсы Serverless базы данных неопределенно большие, то и максимальное потребление Request Units за промежуток времени также может составить любое значение, приведя к нежелательным начислениям. Например, такое может произойти в результате ошибки в коде, приводящей к запросам в бесконечном цикле.
-
-При облачном развертывании {{ ydb-short-name }} на уровне облачных квот существует ограничение на общее количество Request Units в секунду. Но данное ограничение носит технический характер, и достаточно велико, чтобы возможная сумма счета оказалась заметно выше ожиданий. Изменение этого параметра возможно только в сторону увеличения через обращение в техническую поддержку.
-
-Ограничение **Пропускная способность** на Serverless базе данных позволяет вам установить максимальную скорость потребления RU в секунду. С учетом 5 минутного накопления неиспользованных RU, небольшие величины этого ограничения (10 RU/с — значение по умолчанию при создании БД) позволяют успешно осуществлять широкий круг задач разработки и тестирования, а также эксплуатировать приложения с небольшой нагрузкой. При этом величина возможных начислений будет ограничена верхней границей в 2572000 секунд в месяц (30 дней), умноженной на цену за 1 миллион RU. По тарифу, актуальному на момент написания этой документации (13.36 ₽), максимально возможная сумма начислений в месяц составит около 340 ₽.
-
-Ограничение **Пропускная способность** может быть изменено в интерактивном режиме в любой момент, как в сторону увеличения, так и в сторону уменьшения, без ограничений. Это позволяет вам оперативно менять его по мере надобности, например для прогона нагрузочного теста. Интерактивность означает, что изменение применяется с минимальной технологической задержкой, необходимой для распространения информации о новом значении по узлам {{ ydb-short-name }}.
-
-Ограничение **Пропускная способность** может быть установлено в ноль, что приведет к возникновении исключений превышения нагрузки на любом запросе. Это может быть полезно для тестирования реакции вашего приложения на такое исключение, а также аварийному предотвращению продолжения потребления каких-либо ресурсов, если ваше приложение вышло из-под контроля.
-
-Ограничение **Пропускная способность** может быть включено или отключено. Мы рекомендуем всегда держать его включенным, однако его отключение может оказаться полезным, если вам необходимо временно получить от базы данных максимально возможную производительность, например для обработки пакета запросов.
-
-**Особенности применения ограничения на пропускную способность, RU/с**
-
-При превышении ограничения запрос не принимается к исполнению, возвращается ошибка `Throughput limit exceeded`. Получение такой ошибки означает, что запрос можно безопасно повторить позже. При повторе рекомендуется использовать конструкции, поставляемые в составе {{ ydb-short-name }} SDK. В предлагаемых конструкциях реализованы алгоритмы повторов, которые в зависимости от типа и кода ошибки используют разные стратегии повторов: без задержки, с экспоненциальным увеличением задержки, быстрый или медленный повтор и другие.
-
-Ограничение срабатывает с некоторой задержкой, поэтому ошибка `Throughput limit exceeded` возвращается не на запросе, который привел к превышению ограничения, а одном из следующих. После срабатывания ограничения запросы не будут приниматься к исполнению в течение времени, приблизительно равного отношению перерасхода к величине ограничения. Например, если на исполнение единичного запроса потрачено 1000 RU при ограничении в 100 RU/с, то новые запросы не будут приниматься в течение 10 секунд.
-
-Для снижения риска получения отказов при неравномерной нагрузке {{ ydb-short-name }} гибко применяет ограничения, используя механизм резервирования пропускной способности (`burst capacity`). Пока на обработку запросов тратится меньше RU, чем указано в ограничении, неиспользованная пропускная способность резервируется. Во время пика потребления за счет накопленного резерва может быть временно предоставлена большая пропускная способность, чем указано в ограничении.
-
-В {{ ydb-short-name }} резервируется около 5 минут пропускной способности. Резерв позволяет выполнить, например, единичный запрос со стоимостью около `5 мин × 60 с × квота RU/с` без отказа в исполнении следующих запросов. Политика предоставления `burst capacity` может быть изменена.
-
-Квота на количество запросов в бессерверном режиме также является инструментом защиты от оплаты перерасхода ресурсов при сбоях в приложении или атаках на сервис. Наличие механизма `burst capacity` позволяет выставлять в квоте наименьшее значение, при котором ваше приложение работает без получения ошибок `Throughput limit exceeded`, с некоторым запасом на непредвиденный рост нагрузки.
-
-### Ограничения — максимальный объем данных {#volume}
-
-При использовании Serverless базы данных сумма оплаты зависит от объема хранимых данных.
-
-Так как объем хранилища в Serverless базе данных неопределенно большой, то и максимальный объем данных, которые в нем можно разместить, также может составить любое значение, приведя к нежелательным начислениям. Например, такое может произойти в результате ошибки в коде, приводящей к вставке данных в бесконечном цикле, или случайном импорте не того бэкапа.
-
-Ограничение **Максимальный объем данных** на Serverless базе данных позволяет вам ограничить объем данных, который {{ ydb-short-name }} позволит разместить в этой базе данных. По умолчанию для новых баз данных устанавливается ограничение в 50 ГБ, что ограничивает сумму ваших ежемесячных начислений за объем хранимых данных суммой около 650 ₽, по действующему на дату написания этой документации тарифу (13.41 ₽ за 1ГБ, 1ГБ бесплатно).
-
-Ограничение **Максимальный объем данных** может быть изменено в интерактивном режиме в любой момент, как через графическую консоль, так и через CLI, как в сторону увеличения, так и в сторону уменьшения, без ограничений. Это позволяет вам оперативно менять его по мере надобности.
-
-Не рекомендуется устанавливать ограничение **Максимальный объем данных** ниже текущего фактического объема данных, так как в таком состоянии станут недоступны все операции изменения данных, включая DELETE. Уменьшить объем данных можно будет только командами DROP TABLE или DROP INDEX. При случайной установке ограничения ниже фактического объема рекомендуется вернуть его к рабочему значению, превышающему фактический объем с некоторым запасом.
diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
index 6c3ba7cec07..e69de29bb2d 100644
--- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
+++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md
@@ -1,20 +0,0 @@
-
-## Архитектура {{ ydb-short-name }} в разных режимах работы {#arch-diff}
-
-### Разделение compute и storage слоев {#separate-layers}
-
-Важно понимать, что в {{ ydb-short-name }} явно выделены слои storage и compute. Storage слой отвечает за надежное хранение данных на устройствах хранения и репликацию данных между узлами для обеспечения отказоустойчивости.
-
-В {{ ydb-short-name }} данные пользователя хранятся в таблицах, таблицы партицированы. Шард — это сущность, которая отвечает за хранение партиции таблицы (обычно, одной). За изменение данных в шарде отвечает такая сущность как Таблетка — это компонент, реализующий согласованное изменение данных в шарде и решающий проблему распределенного консенсуса. На инстанс таблетки можно смотреть как на объект, который порожден в адресном пространстве процесса и потребляет процессорные ресурсы и оперативную память. Все свое состояние Таблетка хранит в storage слое. Это, в том числе, означает, что инстанс Таблетки может быть поднят в произвольном процессе, откуда доступен storage слой. Compute слой {{ ydb-short-name }} по сути состоит из Таблеток и слоя выполнения YQL-запросов.
-
-Стоит отметить, что понятие базы данных состоит не только из пользовательских таблиц и, соответственно, Таблеток обслуживающих эти таблицы, но и определенных системных сущностей. Например, есть Таблетка SchemeShard, которая обслуживает схему данных всех таблиц, есть система координации распределенных транзакций, элементы которых также представляют собой Таблетки.
-
-### Dedicated режим работы {{ ydb-short-name }} {#dedicated}
-
-Режим работы Dedicated предполагает, что ресурсы на инстансы Таблеток и на выполнение YQL-запросов выбираются из явно выделенных для базы данных compute ресурсов. Под compute ресурсами понимаются виртуальные машины, обладающие определенным количеством vCPU и памяти. Задача выбора оптимального количества ресурсов для базы данных в настоящий момент лежит на пользователе. Если ресурсов будет недостаточно для обслуживания подаваемой нагрузки, то latency запросов начнет увеличиваться, а в пределе будет отказ в обслуживании запросов, например с кодом возврата `OVERLOADED`. Пользователь может добавить compute ресурсы (ВМ) в базу данных в UI или CLI для того, чтобы обеспечить базу данных необходимым количеством вычислительных ресурсов. Добавление compute ресурсов в базу данных происходит относительно быстро и сопоставимо со временем запуска ВМ. Далее {{ ydb-short-name }} автоматически сбалансирует Таблетки по кластеру с учетом добавленных ресурсов.
-
-### Serverless режим работы {{ ydb-short-name }} {#serverless}
-
-В Serverless режиме работы инфраструктура {{ ydb-short-name }} определяет, сколько вычислительных ресурсов необходимо выделить для обслуживания пользовательской базы. Количество выделенных ресурсов может быть как очень большим (произвольное количество ядер), так и очень маленьким (значительно менее одного ядра). Если пользователь создал базу данных из одной таблицы с одной записью в ней, при этом выполняет запросы к базе крайне редко, то {{ ydb-short-name }}, по сути, тратит незначительный объем памяти на инстансы Таблеток, которые входят в состав пользовательской базы. Это возможно за счет того, что компоненты пользовательской базы представляют собой объекты, а не процессы. Если нагрузка возрастает, то компоненты базы начинают потреблять больше процессорного времени и памяти. Если нагрузка возрастает до пределов, когда ресурсов ВМ не хватает, инфраструктура {{ ydb-short-name }} имеет возможность гранулированно балансировать систему, порождая инстансы Таблеток на других ВМ.
-
-Подобная технология позволяет очень плотно упаковывать виртуальные сущности (инстансы Таблеток) в физические ресурсы на основе реального потребления, что дает возможность выставлять счет пользователю за выполненные операции, а не за выделенные ресурсы.
diff --git a/ydb/docs/ru/core/concepts/connect.md b/ydb/docs/ru/core/concepts/connect.md
index 202287b1c48..175d6c48c46 100644
--- a/ydb/docs/ru/core/concepts/connect.md
+++ b/ydb/docs/ru/core/concepts/connect.md
@@ -12,7 +12,6 @@
 
 * `grpc://localhost:7135` — протокол обмена данными без шифрования (gRPC), сервер запущен на том же хосте что и клиент, принимает соединения на порту 7135.
 * `grpcs://ydb.example.com` — протокол обмена данными с шифрованием (gRPCs), сервер запущен на хосте ydb.example.com в изолированной корпоративной интрасети, принимает соединения на порту YDB по умолчанию 2135.
-* `grpcs://ydb.serverless.yandexcloud.net:2135` — протокол обмена данными с шифрованием (gRPCs), публичный сервер Serverless YDB {{ yandex-cloud }} ydb.serverless.yandexcloud.net, порт 2135.
 
 ## Путь базы данных {#database}
 
diff --git a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md b/ydb/docs/ru/core/concepts/serverless_and_dedicated.md
index a80ceb2658e..e69de29bb2d 100644
--- a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md
+++ b/ydb/docs/ru/core/concepts/serverless_and_dedicated.md
@@ -1,5 +0,0 @@
-{% include [intro.md](_includes/serverless_and_dedicated/01_intro.md) %}
-
-{% include [sls_pars.md](_includes/serverless_and_dedicated/02_sls_pars.md) %}
-
-{% include [arch_diff.md](_includes/serverless_and_dedicated/10_arch_diff.md) %}
diff --git a/ydb/docs/ru/core/concepts/toc_i.yaml b/ydb/docs/ru/core/concepts/toc_i.yaml
index 8142ff4fc6a..cf212d183ee 100644
--- a/ydb/docs/ru/core/concepts/toc_i.yaml
+++ b/ydb/docs/ru/core/concepts/toc_i.yaml
@@ -6,7 +6,6 @@ items:
   href: auth.md
 - name: Модель данных и схема
   include: { path: datamodel/toc_p.yaml, mode: link }
-- { name: Режимы работы Serverless и Dedicated,   href: serverless_and_dedicated.md }
 - { name: Типы данных,                            href: datatypes.md, hidden: true } # Deprecated
 - { name: Транзакции,                             href: transactions.md }
 - { name: Вторичные индексы,                      href: secondary_indexes.md }
diff --git a/ydb/docs/ru/core/faq/_includes/all.md b/ydb/docs/ru/core/faq/_includes/all.md
index 7e307b34d53..323cf6825fa 100644
--- a/ydb/docs/ru/core/faq/_includes/all.md
+++ b/ydb/docs/ru/core/faq/_includes/all.md
@@ -20,6 +20,3 @@
 
 {% include notitle [yql.md](../yql.md) %}
 
-## Serverless {#serverless}
-
-{% include notitle [serverless.md](../serverless.md) %}
diff --git a/ydb/docs/ru/core/faq/_includes/index.md b/ydb/docs/ru/core/faq/_includes/index.md
index 71eb9bb51fa..1fcba29248d 100644
--- a/ydb/docs/ru/core/faq/_includes/index.md
+++ b/ydb/docs/ru/core/faq/_includes/index.md
@@ -6,4 +6,3 @@
 {% endif %}
 * [Ошибки](../errors.md)
 * [YQL](../yql.md)
-* [Serverless](../serverless.md)
diff --git a/ydb/docs/ru/core/faq/_includes/serverless.md b/ydb/docs/ru/core/faq/_includes/serverless.md
index 1d301993ad8..e69de29bb2d 100644
--- a/ydb/docs/ru/core/faq/_includes/serverless.md
+++ b/ydb/docs/ru/core/faq/_includes/serverless.md
@@ -1,13 +0,0 @@
-# {{ ydb-short-name }} в Serverless режиме
-
-#### Как вторичные индексы влияют на стоимость запроса?
-
-Операции с индексами оцениваются по тем же правилам, что и операции с таблицами. Они отражаются в статистике исполнения запроса и включаются в суммарные показатели, на основании которых делается расчет стоимости в RequestUnits (RU). Подробнее читайте в [правилах тарификации бессерверного режима для {{ ydb-short-name }} API]{% if lang == "en" %}(https://cloud.yandex.com/en/docs/ydb/pricing/request_units_yql){% endif %}{% if lang == "ru" %}(https://cloud.yandex.ru/docs/ydb/pricing/request_units_yql){% endif %}.
-
-При чтении данных из таблицы с использованием индекса в статистике исполнения запроса будет видно количество считанных из индекса записей и их объем.
-
-При добавлении новой строки в таблицу в каждый индекс, существующий на этой таблице, будет также сделано добавление записи, с отражением в статистике количества добавленных записей и объема записанных данных.
-
-При изменении строки таблицы в статистику попадет операция удаления старой записи из индекса и добавления новой для всех индексов, в которые включены изменяемые поля.
-
-При удалении строки таблицы в статистику попадет удаление записей из всех индексов на этой таблице.
diff --git a/ydb/docs/ru/core/faq/serverless.md b/ydb/docs/ru/core/faq/serverless.md
index 5429ea3430b..e69de29bb2d 100644
--- a/ydb/docs/ru/core/faq/serverless.md
+++ b/ydb/docs/ru/core/faq/serverless.md
@@ -1 +0,0 @@
-{% include [serverless.md](_includes/serverless.md) %}
diff --git a/ydb/docs/ru/core/faq/toc_i.yaml b/ydb/docs/ru/core/faq/toc_i.yaml
index dda8b56a2f9..9202b738729 100644
--- a/ydb/docs/ru/core/faq/toc_i.yaml
+++ b/ydb/docs/ru/core/faq/toc_i.yaml
@@ -10,8 +10,6 @@ items:
   href: errors.md
 - name: YQL
   href: yql.md
-- name: Serverless
-  href: serverless.md
 - name: Все вопросы на одной странице
   href: all.md
 # Essintial for build with contributors, as it fails without that
diff --git a/ydb/docs/ru/core/troubleshooting/_includes/system_views/query_metrics_header.md b/ydb/docs/ru/core/troubleshooting/_includes/system_views/query_metrics_header.md
index 15b86d46022..b78881d0165 100644
--- a/ydb/docs/ru/core/troubleshooting/_includes/system_views/query_metrics_header.md
+++ b/ydb/docs/ru/core/troubleshooting/_includes/system_views/query_metrics_header.md
@@ -42,7 +42,3 @@
 `SumDeleteRows` | Общее количество удалённых строк.<br>Тип: `Uint64`.
 `MinDeleteRows` | Минимальное количество удалённых строк.<br>Тип: `Uint64`.
 `MaxDeleteRows` | Максимальное количество удалённых строк.<br>Тип: `Uint64`.
-`SumRequestUnits` | Общее количество использованных [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options).<br>Тип: `Uint64`.
-`MinRequestUnits` | Минимальное количество использованных [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options).<br>Тип: `Uint64`.
-`MaxRequestUnits` | Максимальное количество использованных [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options).<br>Тип: `Uint64`.
-
diff --git a/ydb/docs/ru/core/troubleshooting/_includes/system_views/tops_header.md b/ydb/docs/ru/core/troubleshooting/_includes/system_views/tops_header.md
index 65050989ee6..d4ed4f2fe35 100644
--- a/ydb/docs/ru/core/troubleshooting/_includes/system_views/tops_header.md
+++ b/ydb/docs/ru/core/troubleshooting/_includes/system_views/tops_header.md
@@ -21,7 +21,6 @@
 --- | ---
 `IntervalEnd` | Момент закрытия минутного или часового интервала.<br>Тип: `Timestamp`.<br>Ключ: `0`.
 `Rank` | Ранг запроса в топе.<br>Тип: `Uint32`.<br>Ключ: `1`.
-`RequestUnits` | Количество затраченных [RequestUnits](../../../concepts/serverless_and_dedicated.md#serverless-options)
 `QueryText` | Текст запроса.<br>Тип: `Utf8`.
 `Duration` | Полное время исполнения запроса.<br>Тип: `Interval`.
 `EndTime` | Момент окончания исполнения запроса. <br>Тип: `Timestamp`.